SQL Server 查询性能优化——覆盖索引
扫描二维码
随时随地手机看文章
覆盖索引又可以称为索引覆盖。
解释一： 就是select的数据列只用从索引中就能够取得，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。
解释二： 索引是高效找到行的一个方法，当能通过检索索引就可以读取想要的数据，那就不需要再到数据表中读取行了。如果一个索引包含了（或覆盖了）满足查询语句中字段与条件的数据就叫做覆盖索引。
解释三： 是非聚集组合索引的一种形式，它包括在查询里的Select、Join和Where子句用到的所有列（即建立索引的字段正好是覆盖查询语句[select子句]与查询条件[Where子句]中所涉及的字段，也即，索引包含了查询正在查找的所有数据）。
首先，从聚集索引说起，聚集索引实际上就是一个覆盖索引，在大多数情况下，可以很直观地分辨出数据表的当前聚集索引是否有用，因为聚集索引根据键值字段控制了数据行的顺序。由于SQL SERVER以聚集索引的键值字段来排序数据行，所以当你经常需要对某些字段排序时，把这些要排序的字段作为聚集索引的键值，创建聚集索引将对查询性能会有很大的提升。因为数据已经照聚集索引的键值字段的顺序排序，所以查询执行时不需要额外的排序操作。同时如果使用聚集索引来查找同条记录的其他字段的数据，SQL SERVER也不需要额外地通过指针检索数据，因为在聚集索引找到索引键值的同时就已经找到整条数据。
聚集索引在检索符合某个范围的数据时也很有用。例如，你想要找到所有销售订单编号介于18000-19999的订单，而聚集索引就是通过销售订单编号字段建立的，相近的记录全部会摆放在一起，则访问的分页当然就比较少，通过聚集索引可快速定位包含起始销售订单编号的行，然后检索表中所有连续的行，直到检索到最后的销售订单号。
聚集索引在检索占总行数比例很大的数据行时也比较有用。
下图是使用聚集索引查找数据的示意图。
使用聚集索引的好处在于：
1）所需要的数据都在子叶层(即数据页)，找到正确的索引键值后不需要再利用指针做额外的查找
2）SQL SERVER将符合相同条件的数据集中放在一起
其次，非聚集索引。非聚集索引结构如下图。
如果想要使建立的非聚集索引同时具备以上两种好处，那就要建立非聚集覆盖索引。通过覆盖索引，所有查询想要的数据字段都是索引键值的一部分，而存放在索引的子叶层级。覆盖索引不仅仅只包含你写在WHERE条件内的字段，而且还包含所有SELECT 需要的字段，以及在GROUP BY 或ORDER BY 子句内的字段。
例：
Select
在SQL SERVER 2000中我们建立覆盖索引采用以下方式
Create index idx on T(C,A,B)
建立组合索引时，字段的顺序很重要，要将条件字段C放在组合索引的第一位，把它做为在索引的上层结构的主要排序对象，且仅有它包含统计数据，也就是非子叶层查找出符合的记录，然后在存放有其他字段记录的子叶层读取所需要的数据。
但是由于字段A,B两列也会在索引的非子叶层出现，除非WHERE条件是多个字段，或多个字段排序，否则索引非子叶层放在其他数据字段用处不大，徒增索引数据量，减低索引性能。
在SQL SERVER 2005可以采用以下方式：
Create index idx on T(C) INCLUDE(A,B...)
为了增强覆盖索引的功能以提升查询效率，SQL SERVER 2005 在Create Index语句中提供INCLUDE参数，将与键值列无关的数据表其他字段添加到非聚集索引的子叶层，扩展非聚集索引的功能，但这些字段值不做排序等额外的维护动作。在查询时仅读取索引结构就可得到所有相关的数据，不访问表或聚集索引的数据，从而减少磁盘 I/O 操作，减少读取数据表本身所花的资源。SQL SERVER 的组合索引最多只能有16个字段，而这些添加到索引子叶层中的相关字段并不计算在这16个字段中。
另外，当查询优化程序在该索引中可以发现处理查询所需要的数据，则虽然组合索引的第一个字段不在WHERE条件内，但查询优化程序仍有可能采取适用的组合索引。或是当查询语句没有WHERE条件，但组合索引覆盖了所有需要的字段时，则直接扫描索引的子叶层获取数据而不是通过扫描数据表查找数据。
示例：
create index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY]([WBOOK_NO]) include([QTY_1],[COP_G_NO],[G_NO],[CODE_T],[UNIT_1],[TRADE_TOTAL],[GROSS_WT])
则索引idx_WBK_PDE_LIST_ORG_HISTROY结构中，包含了以WBOOK_NO键值顺序为主要排序对象的上层结构，以及包含数据表内所有WBOOK_NO与[QTY_1],[COP_G_NO],[G_NO],[CODE_T],[UNIT_1],[TRADE_TOTAL],[GROSS_WT]字段内容的子叶层。如下图。
接下来我用一个实例来解释一下，上图中的情况，我们来看看下面这条SQL语句在SQL执行引擎中是如何执行的：
SELECT G_NO, UNIT_1 FROM [WBK_PDE_LIST_ORG_HISTROY] WHERE [COP_G_NO]= 'BENNET'
1) [WBK_PDE_LIST_ORG_HISTROY] 表在[COP_G_NO]列上有一个非聚集索引，因此它查找非聚集索引的根节点中找出[COP_G_NO]= 'BENNET'的记录。上图中1）
2) 从包含[COP_G_NO]= 'BENNET'记录的索引中间节点中找到指向该记录的子叶层页号。上图中2）
3) 从索引的子叶层中针对每一行数据(假设这里有100条)获取书签（由数据库物理文件编号，对应的Page页码，对应的行号组成），SQL Server引擎通过书签查找从聚集索引或数据表中找出真实的行在对应页面中的位置。上图中3）
4) SQL Server引擎从对应的行查找 G_NO和UNIT_1 列的值。
在上面的步骤中，对[COP_G_NO]= 'BENNET'的所有数据(这里是100条记录)，SQL Server引擎要搜索100次聚集索引或数据表以检索查询中指定的其它列( G_NO, UNIT_1 )。
如果非聚集索引页中包括了查询语句中所需要的数据列(COP_G_NO，G_NO, UNIT_1)的值，SQL Server引擎可能不会执行上面的第3和4步，直接从非聚集索引中查找[COP_G_NO]列速度还会快一些，直接从索引的子叶层读取这三列的数值。
本文将具体讲一下使用不同索引对查询性能的影响。
下面通过实例，来查看不同的索引结构，如聚集索引、非聚集索引、组合索引等来查看相同的SQL语句查询的不同性能
例一：没有任何索引的查询访问
1.表的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就是数据页访问的数量 SET STATISTICS IO ON --没有任何索引情况下的数据页访问数量 SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1568 次，物理读取54 次，预读1568 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读 0 次。 SET STATISTICS IO OFF
例二：通过聚集索引查询访问
1.聚集索引的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就是数据分页访问的数量 SET STATISTICS IO ON ---通过聚集索引查询访问的数据页数量 create clustered index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY](QTY_1) SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取351 次，物理读取4 次，预读345 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 SET STATISTICS IO OFF --- drop index [WBK_PDE_LIST_ORG_HISTROY].idx_WBK_PDE_LIST_ORG_HISTROY ---
例三：强制通过非聚集索引查询访问
1.非聚集索引的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就是数据页访问的数目 SET STATISTICS IO ON --强制通过非聚集索引查询访问的数据页数量，用错索引比不用索引更糟糕 create index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY](WBOOK_NO) SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] with (index(idx_WBK_PDE_LIST_ORG_HISTROY)) where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取61065 次，物理读取864 次，预读727 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 SET STATISTICS IO OFF --- drop index [WBK_PDE_LIST_ORG_HISTROY].idx_WBK_PDE_LIST_ORG_HISTROY
例四：通过字段顺序不适用的覆盖索引查询访问
1.非聚集索引的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就是数据页访问的数量 SET STATISTICS IO ON --通过字段顺序不适用的覆盖索引查询访问的数据页数量 create index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY]([WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT]) SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取687 次，物理读取9 次，预读683 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 SET STATISTICS IO OFF --- drop index [WBK_PDE_LIST_ORG_HISTROY].idx_WBK_PDE_LIST_ORG_HISTROY
例五：通过覆盖索引查询访问
1.非聚集索引的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就是数据页访问的数量 SET STATISTICS IO ON --通过覆盖索引查询访问的数据页数量 create index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY]([QTY_1] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[WBOOK_NO] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT]) SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取178 次，物理读取5 次，预读175 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 SET STATISTICS IO OFF --- drop index [WBK_PDE_LIST_ORG_HISTROY].idx_WBK_PDE_LIST_ORG_HISTROY
例六：通过字段顺序不适用的覆盖索引查询访问
1.聚集索引的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就数据页访问的数量 SET STATISTICS IO ON ---通过字段顺序不适用的覆盖索引查询访问的数据页数量 create index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY]([WBOOK_NO]) include(qty_1 ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT]) SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取682 次，物理读取1 次，预读492 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 SET STATISTICS IO OFF --- drop index [WBK_PDE_LIST_ORG_HISTROY].idx_WBK_PDE_LIST_ORG_HISTROY
例七：通过子叶层覆盖索引查询访问(INCLUDE)
1.聚集索引的碎片情况：
2.SQL查询语句与查询执行计划成本
--要求返回IO统计，也就是数据页访问的数量 SET STATISTICS IO ON --通过子叶层覆盖索引查询访问的数据页数量 create index idx_WBK_PDE_LIST_ORG_HISTROY on [WBK_PDE_LIST_ORG_HISTROY](qty_1) include([WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT]) SELECT [WBOOK_NO] ,[COP_G_NO] ,[G_NO] ,[CODE_T] ,[QTY_1] ,[UNIT_1] ,[TRADE_TOTAL] ,[GROSS_WT] FROM [WBK_PDE_LIST_ORG_HISTROY] where qty_1 between 50 and 500 --表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取177 次，物理读取4 次，预读173 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 SET STATISTICS IO OFF drop index [WBK_PDE_LIST_ORG_HISTROY].idx_WBK_PDE_LIST_ORG_HISTROY
访问方式分页
逻辑读
物理读
预读
估计运算符开销
全表扫描
1568
54
1568
1.06575
以QTY_1字段建立聚集索引
351
4
345
0.275863
以WBOOK_NO字段建非立聚集索引
61065
864
727
14.10295
以[WBOOK_NO],[COP_G_NO],[G_NO],[CODE_T],[QTY_1],[UNIT_1],[TRADE_TOTAL] ,[GROSS_WT]八个字段建复合索引
687
9
683
0.570198
以[QTY_1],[COP_G_NO],[G_NO],[CODE_T],[WBOOK_NO],[UNIT_1],[TRADE_TOTAL],[GROSS_WT]八个字段建复合索引
178
5
175
0.146974
以WBOOK_NO建立索引,include以下字段 [QTY_1],[COP_G_NO],[G_NO],[CODE_T],[UNIT_1],[TRADE_TOTAL],[GROSS_WT]
682
1
492
0.570198
以[QTY_1]建立索引,include 以下字段[WBOOK_NO],[COP_G_NO],[G_NO],[CODE_T],[UNIT_1],[TRADE_TOTAL],[GROSS_WT]
177
4
173
0.146974
例一/例二/例三/例四/例五/例六/例七
8.8/2/345/3.9/1/3.9/1
54/4/864/9/5/1/4
8.8/2/4.1/3.9/1/2.8
7.2/1.9/96/3.9/1/3.9/1
从上表中可以得出一个结论，如果索引使用不当，例如上面的例三——强制使用选择性很低的索引来查找数据（或是索引统计数据错误、优化引擎误判等，造成索引使用不当），反而会导致大量的I/O操作（逻辑读61065次，物理读864次），其成本比进行全表扫描(例一)还高。
例二，通过聚集索引来查找，因为缩小了数据表扫描范围，所以效果较佳。
例五、例七，建立覆盖索引，因为数据结构远小于数据表本身，所以不管组合索引的字段顺序是否正确，都有更好的查询效果。当然 ，依WHERE条件所需要的字段建立索引数据摆放顺序，也就是[QTY_1]放在索引顺序的第一位，再include查询所需要的字段([WBOOK_NO],[COP_G_NO],[G_NO],[CODE_T],[UNIT_1],[TRADE_TOTAL],[GROSS_WT])，其查询性能最佳。
最后要提醒注意：
1） 在建立覆盖查询时要尽量限制索引键值的大小，保持Row-to-key的大小比例差异越大越好。否则扫描覆盖索引与扫描数据表所花的I/O操作差不多，这样就失去了建立覆盖索引的意义。
2) 覆盖索引可以用来提升查询性能，因为索引中包含了所有查询里的列.非聚集索引为表里的每一行用索引键值来存储一行。另外SQL Server能使用索引页级里的这些行来执行聚集计算。这意味着SQLServer不必去实际的表执行聚集计算，这样可以提升性能。
3) 覆盖索引能提升获取数据的性能，但它们也能降低INSERT、UPDATE和DELETE操作的性能。这是因为维护覆盖索引要求做一些额外的工作。通常这不是问题，除非你的数据库经常进行非常高的INSERT、UPDATE和DELETE操作。你也许不得不在你的产品系统上应用覆盖索引之前，要先进行实验，看看你所建立的覆盖索引是否在提升性能方面上比影响性能方面更有帮助。
4) 应该在那些SELECT查询中常使用到的列上创建覆盖索引，但覆盖索引中包括过多的列也不行，因为覆盖索引列的值是存储在内存中的，这样会消耗过多内存，引发性能下降。
关于索引碎片的修复：
关于上图的一些说明：
avg_fragmentation_in_percent:逻辑碎片（索引中的无序页）的百分比。这是索引的叶级页中出错页所占的百分比。对于出错页，分配给索引的下一个物理页不是由当前叶级页中的“下一页”指针所指向的页。
fragment_count : 索引中的碎片（物理上连续的叶页）数量。
avg_fragment_size_in_pages :索引中一个碎片的平均页数。
知道索引碎片程度后，可以使用下表确定修复碎片的最佳方法。
avg_fragmentation_in_percent 值
修复语句
> 5% 且 < = 30%
ALTER INDEX REORGANIZE
> 30%
ALTER INDEX REBUILD WITH (ONLINE = ON)
下载文档
