在执行计划之前（因为我正在调试一个运行不佳的计划）我有这个变量分配块：
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索引，这是正确的索引，因为我在DGItemIDand上匹配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_ROWSas1,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）并重新运行它，结果没有变化 - 哈希匹配仍在溢出。