由于Table Scan和Clustered Index Scan实质上都扫描表中的所有记录，因此为什么说"聚集索引扫描"更好？
举个例子-当有很多记录时，以下各项之间的性能差异是什么？：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| DECLARE @temp TABLE(
SomeColumn VARCHAR(50)
)
INSERT INTO @temp
SELECT 'SomeVal'
SELECT * FROM @temp
-----------------------------
DECLARE @temp TABLE(
RowID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
SomeColumn VARCHAR(50)
)
INSERT INTO @temp
SELECT 'SomeVal'
SELECT * FROM @temp |
在没有聚集索引的表(堆表)中，数据页未链接在一起-因此遍历页需要查找索引分配图。
但是，一个群集表将其数据页链接在一个双向链接列表中，这使得顺序扫描的速度更快。当然，作为交换，您需要承担将数据页保持在INSERT，UPDATE和DELETE上的顺序的开销。但是，堆表需要第二次写入IAM。
如果您的查询具有RANGE运算符(例如：SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100)，则聚簇表(按有保证的顺序)将更加高效-因为它可以使用索引页来查找相关的数据页。堆将不得不扫描所有行，因为它不能依赖于排序。
而且，当然，聚集索引使您可以执行聚集索引SEEK，这对于性能而言是非常理想的……没有索引的堆将始终导致表扫描。
所以：
-
对于选择所有行的示例查询，唯一的区别是聚簇索引维护的双链表。这应该使您的集群表比具有大量行的堆快一点。
-
对于具有WHERE子句的查询(该查询可以(至少部分地)由聚集索引满足)，由于排序的原因，您将走在前面-因此您不必扫描整个表。
-
同样，对于聚集索引无法满足的查询，您甚至可以...甚至，唯一的区别是用于顺序扫描的双链表。无论哪种情况，您都不理想。
-
对于INSERT，UPDATE和DELETE，堆可能会赢也可能不会赢。堆不必维护顺序，但是确实需要对IAM进行第二次写入。我认为相对性能差异可以忽略不计，但还取决于数据。
Microsoft拥有一份白皮书，该白皮书将堆中的聚集索引与等效的非聚集索引进行了比较(与我上面讨论的不完全相同，但是很接近)。他们的结论基本上是在所有表上放置聚簇索引。我将尽力总结他们的结果(再次，请注意，它们实际上是在这里将非聚集索引与聚集索引进行比较-但我认为它是相对可比较的)：
-
INSERT性能：由于堆需要进行第二次写入，因此聚集索引的赢率约为3％。
-
UPDATE性能：由于堆需要进行第二次查找，因此聚集索引的赢率约为8％。
-
DELETE性能：由于需要对IAM进行第二次查找和对堆进行第二次删除，因此聚集索引的赢率约为18％。
-
单个SELECT性能：由于需要对堆进行第二次查找，因此聚集索引的赢率约为16％。
-
范围SELECT性能：由于对堆的随机排序，聚集索引的获胜率约为29％。
-
并发INSERT：由于聚集索引的页面拆分，堆表在负载下获胜30％。
http://msdn.microsoft.com/zh-CN/library/aa216840(SQL.80).aspx
聚集索引扫描逻辑和物理运算符将扫描"参数"列中指定的聚集索引。当存在可选的WHERE :()谓词时，仅返回满足该谓词的那些行。如果Argument列包含ORDERED子句，则查询处理器已请求按聚集索引对行进行排序的顺序返回行的输出。如果不存在ORDERED子句，则存储引擎将以最佳方式扫描索引(不保证对输出进行排序)。
http://msdn.microsoft.com/zh-CN/library/aa178416(SQL.80).aspx
表扫描逻辑和物理运算符从"参数"列中指定的表中检索所有行。如果WHERE :()谓词出现在Argument列中，则仅返回满足该谓词的那些行。
表扫描必须检查表的每一行。聚集索引扫描仅需要扫描索引。它不会扫描表中的每条记录。确实，这就是索引的意义。
