聚集索引扫描与非聚集索引查找之间最好的是什么

Question

我正在尝试找出最佳选择，我的主要要求是减少 IO。

• 我有一个包含 500M 记录的表，下面提到的查询是在表上选择默认的聚集索引扫描。
• 我试图创建一个覆盖非聚集索引，但它仍然选择聚集索引扫描作为默认值。所以我强迫它使用覆盖索引，我的观察是逻辑读取从 3M 下降到 1M，但 CPU 和持续时间增加了。
• 我正在尝试了解这种行为以及这里的最佳做法。

查询：

set statistics time, io on;
select 
    min(CampaignID), 
    max(CampaignID) 
from Campaign
where datecreated < dateadd(day, -90, getutcdate())
go
CREATE NONCLUSTERED INDEX [NCIX] 
ON [dbo].[Campaign](DateCreated)
INCLUDE (Campaignid)
go
select 
    min(CampaignID), 
    max(CampaignID) 
from Campaign with (index = NCIX)
where datecreated < dateadd(day, -90, getutcdate())
set statistics time, io off;

消息：

(1 row affected)
Table 'Campaign'. Scan count 2, logical reads 3548070, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

(8 rows affected)

(1 row affected)

 SQL Server Execution Times:
   CPU time = 14546 ms,  elapsed time = 14723 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 3 ms.

(1 row affected)
Table 'Campaign'. Scan count 1, logical reads 1191017, physical reads 0, page server reads 0, read-ahead reads 19, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

(6 rows affected)

(1 row affected)

 SQL Server Execution Times:
   CPU time = 163953 ms,  elapsed time = 164163 ms.

执行计划：

Complete execution plan

Answer 1

首先，没有“最佳”运算符。有时读取更多数据比读取一些数据并对其进行按摩以获得我们的结果更有效。 “最好”，因为几乎所有事情都是相对的。

让我们试着了解在 cmets 中发生了什么...

查询

select 
    min(CampaignID), 
    max(CampaignID) 
from Campaign
where datecreated < dateadd(day, -90, getutcdate())

上面写着：

我想要日期小于固定日期的任何记录的第一个和最后一个 ID（最小值/最大值）。

集群

没有索引/索引提示的第一个查询执行了 SQL Server 认为比读取任何索引更便宜的操作，即使它需要更多 IO（磁盘使用）。这是因为在验证表中的记录时找到最小值和最大值比选择表的一半，然后重新排序/聚合它们找到完全相同的信息要便宜。

聚集索引将所有数据存储在磁盘上，并按键列进行逻辑排序，在本例中为 CampaignID（我假设）。这意味着，找到最小和最大 ID 很容易：最小值是与条件匹配的第一个 ID -> 让我们从第一个 ID 检查每个 ID，并在找到日期所在的记录后停止（这将很可能是第一个）。最大值是从索引末尾开始匹配条件的第一条记录。

以日期为键的索引

CREATE NONCLUSTERED INDEX [NCIX] 
ON [dbo].[Campaign](DateCreated)
INCLUDE (Campaignid)

有了第一个索引（日期作为关键列），SQL Server 可以使用日期来过滤数据，没错，但它对排序没有帮助。它仍然需要检查该索引中的每条记录，并从一组可能无序的值中找出最小值和最大值。

以 ID 为键的索引

CREATE NONCLUSTERED INDEX [NCIX] 
ON [dbo].[Campaign](Campaignid)
INCLUDE (DateCreated)

对于第二个索引，其中 ID 是键列，SQL Server 可以使用与聚集键相同的技巧。唯一的区别是没有其他数据可以读取，只有 ID 和日期，比整条记录要小得多，因此它可以容纳更少的页面，并且需要更少的 IO。

即使没有索引提示，SQL Server 也很可能会选择第二个索引。

第二个索引的工作原理（查询近似）

您可以通过

获得最小的Campaignid

SELECT TOP(1)
  Campaignid
FROM
  [dbo].[Campaign]
WHERE
  datecreated < dateadd(day, -90, getutcdate())
ORDER BY
  Campaignid ASC

和非常相似的查询的最大值

SELECT TOP(1)
  Campaignid
FROM
  [dbo].[Campaign]
WHERE
  datecreated < dateadd(day, -90, getutcdate())
ORDER BY
  Campaignid DESC

如果您将它们作为子查询交叉加入，您几乎可以得到执行计划所描述的内容。

备注

在这里我要补充一点：仅针对一个查询进行优化并不总是最好的策略。您无法针对所有内容进行优化，如果此查询每天/每周/每季度运行一次，那么使用集群键的 14-15 秒运行时间很可能不会造成任何伤害。如果索引对其他查询没有帮助，我不会创建它，除非它是关键任务查询。