面向初学者的 SQL Server 查询执行计划(1)——聚集索引运算符(Clustered Index)

在本文中，我们将讨论与聚集索引相关的各种执行计划运算符，以及它们的作用、它们何时出现以及它们何时出现。

执行计划中的每一个运算符都会提供一些有关 SQL Server 运行方式的指标。

我们需要理解这些运算符为什么会出现，以及采取措施避免某些不必要的运算符再次出现。

首先我们从表扫描开始。

表扫描(Table Scan)

出现场合：在访问没有聚集索引的表时，SQLServer会使用表扫描(Table Scan) 运算符。
好或坏：对于数据量非常小的表，性能上没有什么区别。如果存在大量数据行，性能上会有较大影响。
改善行动：给表创建聚集索引。一个推荐的实践是，如果表上只有一个索引，最好创建一个聚集索引。

接下来我们看看表扫描(Table Scan) 运算符的示例。我们使用以下脚本创建一个堆表(MySalesOrderDetail)

USE AdventureWorks2014
GO
SELECT *
INTO [dbo].[MySalesOrderDetail]
FROM [Sales].[SalesOrderDetail]
GO

注意源表( [Sales].[SalesOrderDetail])上有聚集索引(Clustered Index)，而新表(MySalesOrderDetail)上未创建索引。

首先，让我们做一个简单查询获取所有数据，并设定显示实际执行计划和统计 IO :

SET STATISTICS IO ON
GO
SELECT *
FROM [dbo].[MySalesOrderDetail]

从输出信息中我们可以看到，我们得到了 121,317 行的结果，其中逻辑读的次数为 1,497。

接着，让我们设定条件范围后，运行相同的查询：

SET STATISTICS IO ON
GO
SELECT *
FROM [SQL_SHACK].[dbo].[MySalesOrderDetail]
WHERE SalesOrderID = 60726 AND SalesOrderDetailID = 74616

可以看到在没有聚集索引(Clustered Index)情况下，虽然结果只获取了一条数据。但是SQL Server执行了表扫描(Table Scan)操作，逻辑读的执行次数与获取全部数据的查询的执行次数是一样的。

聚集索引扫描(Clustered Index Scan)

出现场合：访问带有聚集索引的表

该表没有非聚集索引
查询不能使用非聚集索引

好或坏： 聚集索引扫描(Clustered Index Scan) 运算符也是一个耗时的操作。除了从该特定表中检索大量数据行的情况之外，聚集索引扫描运算符会降低性能。
改善行动：评估聚集索引键是否合理

聚集索引查找(Clustered Index Seek)

出现场合：正在访问具有聚集索引的表，并且 B 树结构能够根据您的聚集索引缩小范围，以从表中获取有限的数据集。
好或坏： 通常情况下使用聚集索引查找(Clustered Index Seek)运算符都是最优案
改善行动：评估使用非聚集索引的可能性。可能可以去除额外的聚集索引查找(Clustered Index Seek)操作。

对于之前创建的表“MySalesOrderDetail”，我们将在 [SalesOrderID] 和 [SalesOrderDetailID] 上创建聚集索引主键。

ALTER TABLE [dbo].[MySalesOrderDetail]
ADD CONSTRAINT [PK_MySalesOrderDetail_SalesOrderID_SalesOrderDetailID]
PRIMARY KEY CLUSTERED
([SalesOrderID] ASC,[SalesOrderDetailID] ASC
)
GO

让我们再次执行获取所有数据的简单查询：

SET STATISTICS IO ON
GO
SELECT *
FROM [dbo].[MySalesOrderDetail]

我们可以看到查询的结果为 121,317 行。与之前无索引状态下得到的结果一样。

另外有一个奇怪的现象，这次查询执行了1,502 次逻辑读取。相比无索引状态下的 1,497 次逻辑读取，索引查询下多了一些逻辑读取。多出来的 5 个的逻辑读取操作是扫描索引树所需要的额外操作。

再查看详细执行计划，您可以看到这次查询采用了 聚集索引扫描(Clustered Index Scan) 操作, 相比之前的 表扫描(Table Scan) 操作, 这是改进的地方。

然后我们在看看一个具体案例。还是之前的示例一样，我们设定查询关键字获取一条数据:

SET STATISTICS IO ON
GO
SELECT *
FROM [SQL_SHACK].[dbo].[MySalesOrderDetail]
WHERE SalesOrderID = 60726 AND SalesOrderDetailID = 74616

可以看到，本次查询只执行了3次逻辑读取操作。从详细执行计划，可以看到前一种情况下的 聚集索引扫描(Clustered Index Scan) 已转换为 聚集索引查找(Clustered Index Seek)。因此 SQL Server 能够使用聚集索引键缩小范围，基于Where条件以获得此特定值。

概括

执行计划是优化查询性能的一个非常重要的工具。每个 DBA 都需要知道执行计划中出现的所有运算符，并判断该运算符是好是坏，如果是坏的状况，如何优化消除。本文简单地讨论有关仅与聚集索引相关的运算符的基础细节。

本系列下一篇文章：

面向初学者的 SQL Server 查询执行计划——非聚集索引运算符