原文:第六章——根据执行计划优化性能（2）——查找表/索引扫描

前言：

在绝大部分情况下，特别是从一个大表中返回少量数据时，表扫描或者索引扫描并不是一种高效的方式。这些必须找出来并解决它们从而提高性能，因为扫描将遍历每一行，查找符合条件的数据，然后返回结果。这种处理是相当耗时耗资源的。在性能优化过程中，一般集中于：

1、 
CPU

2、 
Network

3、 
磁盘IO

而扫描操作会增加这三种资源的开销。

准备工作：

下面将创建两个表来查看不同的物理关联操作的不同影响。创建脚本已经在本系列的第一篇中给出，这里不再显示。

步骤：

1、 
打开执行计划并运行下面查询：

SELECT  sh.*
FROM    SalesOrdDetailDemo AS sd
        INNER JOIN SalesOrdHeaderDemo AS sh ON sh.salesorderID = sd.salesorderid
WHERE   sh.orderdate = ‘2004-07-31 00:00:00.000‘
GO

从执行计划的截图可以看到两表均使用了表扫描，其中执行计划建议了丢失索引。此时应该考虑是否有必要创建：

2、 
为了避免表扫描，创建一个聚集索引在表SalesOrdHeaderDemo中：

CREATE UNIQUE CLUSTERED INDEX idx_salesorderheaderdemo_SalesOrderID ON salesordheaderdemo(SalesOrderID)
GO

3、 
再次运行步骤1中的查询，看看执行计划是否已经移除了表扫描：

4、 
上图中可以看到创建了聚集索引的表已经变成了聚集索引扫描，但是未创建的就还是表扫描，观察聚集索引扫描，它只是把表扫描换成了聚集索引扫描，所以没有很大的性能提升。

5、 
现在继续把第二个表的表扫描去掉，通过创建在这个表上的唯一聚集索引：

CREATE UNIQUE CLUSTERED INDEX idx_SalesDetail_SalesOrderID ON SalesOrdDetailDemo(SalesOrderID,SalesOrderDetailID)

GO

6、 
再次执行查询。

7、 
下面截图中可以看到表扫描已经彻底移除：

分析：

在深入讨论之前，首选需要澄清的是，扫描并不总是坏的，而查找并不总是好的，但是在绝大部分情况下，特别是在大表中返回少量数据时，查找会有更好的性能表现。同样，并不总是有方法在每个查询中移除扫描操作。如果查询的性能问题是因为扫描，那么移除扫描操作会更好，否则，看看是否有什么改变方式去提高性能。

在第一步中，因为两表均没有索引，所以优化器只能选择扫描来查找数据。

在第三步中，已经创建了一个聚集索引在SalesOrdHeaderDemo表上，表扫描变成了聚集索引扫描，聚集索引查找是我们希望得到的结果，但是因为我们没有什么谓词在第一个表上，所以只能扫描整个聚集索引来代替扫描整个表。

在第六步中，在第二个表也创建了聚集索引，且有一个谓词在这个表上，所以出现了聚集索引查找，而不是聚集索引扫描。