SQL SERVER 为两个相似的查询生成不同且未优化的执行计划

Question

以下两个查询是用 SQL SERVER 执行的

SELECT TOP(10) [c].[Name] AS [I0], [c].[Surname] AS [I1],(
    SELECT MAX([r].[Date])
    FROM [Presences].[Regs] AS [r]
    WHERE ([c].[Id] = [r].[ColId]) AND [r].[ColId] IS NOT NULL) AS [I7], [c].[Id] AS [I10]
FROM [Presences].[Cols] AS [c]

SELECT TOP(10) [c].[Code] AS [I0], [c].[Description] AS [I1], (
    SELECT MAX([r].[Date])
    FROM [Presences].[Regs] AS [r]
    WHERE ([c].[Id] = [r].[CantId]) AND [r].[CantId] IS NOT NULL) AS [I9], [c].[Id] AS [I10]
FROM [Presences].[Cants] AS [c]

第二个查询的计算时间不到 1 秒，但第一个查询的计算时间超过 20 秒。

事实上，第一个生成的执行计划非常不同：

Bad execution plan of the first query

如果与第二个相比：

Good execution plan of the second query

我不清楚为什么不选择索引搜索。

这些是在表 [Regs] 上声明的索引：

CREATE NONCLUSTERED INDEX [IX_Regs_Date] ON [Presences].[Regs]
(
    [Date] ASC
)

CREATE NONCLUSTERED INDEX [IX_Regs_ColId] ON [Presences].[Regs]
(
    [ColId] ASC
)

CREATE NONCLUSTERED INDEX [IX_Regs_CantId] ON [Presences].[Regs]
(
    [CantId] ASC
)

表格 [Cols] 有大约 600 行，表格 [Cants] 有 21000 个。

有趣的事实是，以下查询（使用 FORCESEEK）生成了正确的执行计划：

SELECT TOP(10) [c].[Name] AS [I0], [c].[Surname] AS [I1],(
    SELECT MAX([r].[Date])
    FROM [Presences].[Regs] AS [r]
    WITH (FORCESEEK)  
    WHERE ([c].[Id] = [r].[ColId]) AND [r].[ColId] IS NOT NULL) AS [I8]
FROM [Presences].[Cols] AS [c]
ORDER BY [c].[Name], [c].[Surname]

但我无法指定此提示，因为查询是使用 ORM 生成的。

如果您需要更多信息，我很乐意提供。

Answer 1

您的问题查询是

SELECT TOP(10) c.Name                      AS I0,
               c.Surname                   AS I1,
               (SELECT MAX(r.Date)
                FROM   Presences.Regs AS r
                WHERE  ( c.Id = r.ColId )) AS I7,
               c.Id                        AS I10
FROM   Presences.Cols AS c 
ORDER BY c.Name, c.Surname

好的计划和坏计划的顶部是相同的

它扫描Cols 表，按Name, Surname 排序，然后继续计算Presences.Regs 中的MAX(Date)，其中r.ColId 与外行中对应的c.Id 匹配。

理想的索引是ColId, Date 上的一个索引——因此它可以查找索引并读取该ColId 的最后一个索引。

你没有这个索引，所以它有两个选择

1. 扫描IX_Regs_Date - 这是按日期顺序，因此它可以在找到与c.Id = r.ColId 匹配的第一行后立即停止扫描
2. 寻找IX_Regs_ColId。获取与谓词匹配的所有行，然后将它们聚合以找到MAX。

对于选项 1，它估计平均每次扫描只需读取 283 行，然后才能找到第一个匹配 c.Id = r.ColId 的行。实际上，每次执行它读取1,358,719（并且有 10 次执行，因此这对应于 1358 万个键查找）。表中有1,517,230 行，因此看起来好像出于某种原因，所有匹配连接的行都聚集在表中的较晚日期。

解决此问题的最简单方法是为其提供理想的索引ColId, Date - 这涵盖了查询，因此即使在“好”计划中也会删除存在的查找，并且是明显的最佳选择，因此将删除诱惑 SQL Server 选择“坏”计划。

--Suggested replacement for IX_Regs_ColId
CREATE NONCLUSTERED INDEX [IX_Regs_ColId_Date] ON [Presences].[Regs]
(
    [ColId] ASC,
    [Date] ASC
)