Question

我有这个查询，我知道这个查询没有高度优化。它可以完成工作，但是非常耗时且未优化

select distinct w.packageid, e.OrgPackageEmailId
from epnunitsettings u,
wippackages w,
epnuser2unit n,
EpnOrgPackageEmails e,
aspnet_users r,
epnorgsettings g,
epnpackages k 
where u.SendPackageEmail = 'true'
and w.unitid = u.unitid
and n.unitid = u.unitid
and e.unitid = u.unitid
and e.userid = r.userid
and e.disabled = 'false'
and g.orgid = e.orgid
and not exists (select 1 from WipPackageEmails
where packageid = w.packageid
and OrgPackageEmailId = e.orgpackageemailid)
and g.orgid in (3163,3261)
and g.SendPackageEmail = 'true'
and w.packageid = k.wippackageid
and k.status < 10000

Answer 1

就像每个人都评论过的一样，如果至少提供以下信息，则可以最好地解决性能问题：

基础表的大小
基础表中的索引详细信息
执行计划屏幕截图

在没有这些细节的情况下，我将尝试提供一些非常通用的建议，供您试用：

请使用ANSI JOINS重新编写查询，从而提供所需的联接筛选器，以尽早帮助SQL Server 通过避免不必要的行来指导制定更好的计划尽早摆桌子。
请尝试确保用于“搜索”的所有列和“排序”（联合列，where子句和搜索列，查询中的分组依据，排序依据，不同）是一些有用的键查询可以使用的索引。我建议创建具有所有必需键的复合非聚集索引该表覆盖了表中的联接和搜索而不是在每个字段上创建单独的非聚集索引。因为您拥有的非聚集索引越多，跳转到的次数就越多 SQL Server必须制作单独的数据页才能得到它需要，这将比查找所有字段慢在一起需要。
请记住，SQL Server可以将表的一个索引用于连接到另一个表（除非它必须执行Key或RID查找）从非聚集索引中查找使用的其他必需列在聚集索引中的加入/选择/搜索中）。因此，要聪明同时提出与此相关的索引策略并确保您有一个综合索引来解决这个问题。只有那样你才会能够在执行计划中看到“索引搜寻”而不是很多许多“索引扫描”和“查找”。
请确保来自不同表的联接列是相同的数据类型，以避免隐式转换昂贵。普通搜索也是如此。如果不是，那你可以接受我的评论中提供的一些建议： Why "IN " query tag is so costly in sql stored procedures?
如以上链接所述，如果您加入的数据类型不是同样，然后在加入时必须使用CONVERT（）函数条件/搜索以避免隐式转换，您应该考虑创建列存储索引而不是行存储索引，以确保该查询可以适当地利用该列的索引。
即使有了正确的索引，如果仍然看不到确定在执行计划中正确使用了索引表格中的统计信息有时不会更新。在这种情况下，请立即更新这些表中的统计信息。

SQL选择不同的查询优化问题

1 个答案: