为什么有时表扫描比索引扫描快？答案

【问题标题】：Why sometimes table scan is faster then index scan?为什么有时表扫描比索引扫描快？
【发布时间】：2015-01-25 10:04:40
【问题描述】：

我创建了一个表来测试正在读取的逻辑块的数量和查询优化器选择的执行计划，比较该表有索引和没有索引时的查询。

测试表是

 create table scan
 ( 
      id int identity(1, 1), 
      a varchar(10), 
      b varchar(10),
      c varchar(10), 
      d varchar(10), 
      e varchar(10), 
      f varchar(10) 
)

当我运行这些查询时：

select * from scan
select id from scan

我得到了 88 和 58 个逻辑读取，以及一个表扫描算法

然后我更改放置 pk 约束和他的聚集 id 的表

alter table scan
add constraint fk_id primary key (id)

然后运行相同的查询：

select * from scan
select id from scan

我得到了 90 和 60 次扫描读取和索引扫描算法

问题是：如果查询优化器选择了运行查询的最佳方式，那么如果表扫描可以读取更少的块，为什么还要选择索引扫描呢？

【问题讨论】：

你只是在读取所有的行——索引没有做任何事情。添加一个 WHERE 子句，看看会发生什么。
查询优化器预测运行查询的最佳方式。它通常不可能在不检查数据的情况下知道最好的方法，这会破坏目的。因此，它不会总是选择绝对最佳的策略，但选择一个非常好的策略应该是相当可靠的。您的数据表明并非如此。
您的数字是实际读取还是估计读取？在这么小的表上，索引不太可能特别有用。
@GordonLinoff，我使用 SET STATISTICS IO ON 获得的那些数字。检查我在上面答案中的评论。这是我对这些数字的怀疑

标签： sql sql-server indexing query-optimization sql-execution-plan

【解决方案1】：

当您创建主键约束时，默认情况下它是集群的。这意味着您之前的堆已按此键排序（在您的情况下为id）。

表中的数据可以通过以下两种方式之一进行存储：堆或聚集索引。当后者被创建时，前者就消失了。所以 SQL Server 不可能对索引执行表扫描——它只能是索引扫描（聚集索引扫描，顺便说一句——这很重要）。

我知道这听起来可能令人困惑，但请尝试阅读一些关于聚集索引的基础知识 - 这可能会有所帮助。

【讨论】：

但我仍然不知道为什么它使用索引读取的块比使用表扫描读取的块多。没有索引，我有 7 列，假设每列有 1kb，块是 14kb，所以每个块读取 2 行。使用索引，我们有 2 列，一列用于索引，另一列用于指向行地址的指针。如果你每个也有 1kb，那么块知道将有 7 行。所以我正在用更少的块阅读更多的信息。我认为在 SELECT * 的情况下它应该读取比表扫描更少的块或比表扫描更多的块，因为它会读取“索引表”和真实表。
@Mucida，堆在物理上实现为双链表，其中每个表页都有 2 个指针——在堆中的前一页和下一页。聚集索引被实现为 B 树，因此它为根和中间级别页面消耗更多空间（平均约为表大小的 1%）。根据您的表是否为堆，将使用表扫描（即堆扫描）或聚集索引扫描。而且您不能同时在磁盘上为同一个表创建两个结构 - 毕竟它只是一个表。
是的，查询优化器使用一组有些晦涩难懂的算法来确定您的查询最终将检索表的多大部分。随着selected pages/total pages 比率的下降（通过增加表大小或缩小搜索条件），在某些时候它开始倾向于搜索而不是扫描。
@Mucida，因为在某些时候它决定使用非聚集索引快速定位行然后执行一些 RID 查找（这非常昂贵）比扫描整个堆表更便宜。一切都与成本有关。
@Mucida，是的，它就是这样工作的。这个等式中还有其他几个标准，但通常都是关于 IO 的。顺便说一句，您始终可以尝试使用提示强制执行某些特定策略，并比较生成的执行计划及其有效性。除非统计数据已过时或索引严重碎片化，否则查询优化器很少会错过重点。