在执行计划之前(因为我正在调试一个运行不佳的计划)我有这个变量分配块:
DECLARE @Days INT = 180
DECLARE @DateRangeFrom DateTime = DATEADD(d, -@Days, getDate())
DECLARE @DateRangeTo DateTime = getDate()
DECLARE @FacilityID INT = 1010
DECLARE @Answer0 INT = 1879
DECLARE @Answer1 INT = 1949
DECLARE @Answer1SetID INT = 1607
DECLARE @Answer2 INT = 1907
DECLARE @Answer2SetID INT = 1593
我的第一个问题是我在 IRItemAnswer_Info 表(节点 ID 19)上执行的查找。它溢出到 Tempdb,它已经开始错误地开始查询。它引用了IRItemAnswerInfo_DGItemID_AnswerSourceID
索引,这是正确的索引,因为我在DGItemID
and上匹配AnswerSourceID
,然后返回IncidentID
。索引创建为
CREATE NONCLUSTERED INDEX IRItemAnswerInfo_DGItemID_AnswerSourceID
ON dbo.IRItemAnswer_Info (DGItemID, AnswerSourceID)
INCLUDE([IncidentID], [AnswerBoolean])
但是,查询的估计行数为 53,459,实际行数为 969,812。
我刚刚完成了强制新的统计数据UPDATE STATISTICS IRItemAnswer_Info IRItemAnswerInfo_DGItemID_AnswerSourceID WITH FULLSCAN
,它没有任何区别。
DBCC SHOW_STATISTICS ('IRItemAnswer_Info', 'DGItemID')
因为DGItemID=1949
有EQ_ROWS
as1,063,536
和
DBCC SHOW_STATISTICS ('IRItemAnswer_Info', 'AnswerSourceID')
因为AnswerSourceID=1607
有EQ_ROWS
_970,079
数据库正在运行兼容级别 140 (SQL Server 2017)。我们将运行 2019 年,但在执行此操作之前,我们需要在存储过程中纠正一些问题。
我接下来要看什么?
我选择了性能最差的输出,这是最常见的值。 IRItemAnswer_Info
是一个包含用户定义的与事件相关联的答案的表格,其中DGItemID=1949
是最常见的问题之一(几乎每个事件都有一个),而AnswerSourceID=1607
最常见的答案是哪里。鉴于它们之间存在很强的相关性,我应该如何重新排序查询?
由于有点混乱,INNER JOIN
同一张表有两个 s,IRItemAnswer_Info
。一个是我正在寻找的答案(由问题iria.DGItemID=1879
及其输出iria.AnswerSourceID
链接确定irai.AltLabel
),第二个是一个限制因素。我只想要问题iiai1.DGItemID=1949
作为答案的记录iiai1.AnswerSourceID=1607
。
我已经明确地从缓存中删除了计划(使用DBCC FREEPROCCACHE
)并重新运行它,结果没有变化 - 哈希匹配仍在溢出。
正如相关问答中所讨论的,SQL Server 如何知道谓词是相关的?SQL Server 默认假定谓词是完全独立的。
它仅在单个前导列上具有详细的统计信息(直方图),即使在使用多列索引或统计信息的情况下也是如此。那么问题是如何组合来自两个独立谓词的两个统计直方图。
例如,假设您有一个带有 的查询
WHERE c1 = x AND c2 = y
。根据直方图信息计算出的选择性为c1 = x
0.2。c2 = y
从单独的直方图中计算出的选择性为0.1。两个谓词在一起的选择性是什么?0.2? 0.1? 0.2 x 0.1?中间某个地方?
如果没有特定的附加信息,SQL Server 必须做出有根据的猜测。最初的默认设置是假设完全独立。较新的基数估计框架使用指数退避(“介于两者之间”选项)。
您的情况略有不同,因为您对多列索引中的列进行了两次相等测试,该索引带有多列统计信息。这些并不像听起来那么宏伟。我们仍然只得到前列的直方图,但统计对象确实包含多列的平均密度信息。
例如,(a,b,c) 上的索引将提供 (a)、(a,b) 和 (a,b,c) 的密度信息。这个频率信息确实捕捉到了一些关于相关性的信息,但它在每个级别都是一个数字。这意味着在给定相同数量的列的情况下,基于频率的估计将始终产生相同的估计。
SQL Server 确实从多列频率信息中生成选择性估计,但它也从各个列直方图(如果可用)计算选择性。直方图估计假设独立,并且不使用指数退避。
如果它比基于频率的估计具有更高的选择性,则服务器选择基于直方图的估计。在您的示例中似乎就是这种情况。
根据问题中的信息,个人选择性是:
假设独立,因为
AND
我们将这些选择性相乘,然后乘以全表基数以产生行估计:有许多内部模型变体以不同的方式处理任务。只有少数被公开记录并通过提示或跟踪标志公开。
通常,以下提示似乎会有所帮助:
文档
不幸的是,当基数估计从使用多列统计的基于频率的计算开始时,该提示不适用。
使用原始 CE 模型,您可能会获得更好的结果:
试试这个索引
如果这没有帮助,我会考虑的另一件事是将索引作为单个选择(无连接)进行故障排除并将结果直接放入临时表中,然后稍后再加入。
例如,试试下面的查询,看看你是否能得到正确的估计。如果可以,那应该确认您找到了正确的索引。然后将其他所有内容重新绑定。
您可以尝试以下重写:
您也可以尝试:
至少,检查你是否有这些索引:
如果没有创建它并测试...