SQL Server 查询性能优化——覆盖索引(一)

覆盖索引又可以称为索引覆盖。
  解释一: 就是select的数据列只用从索引中就能够取得,不必从数据表中读取,换句话说查询列要被所使用的索引覆盖。
  解释二: 索引是高效找到行的一个方法,当能通过检索索引就可以读取想要的数据,那就不需要再到数据表中读取行了。如果一个索引包含了(或覆盖了)满足查询语句中字段与条件的数据就叫做覆盖索引。
  解释三: 是非聚集组合索引的一种形式,它包括在查询里的SelectJoinWhere子句用到的所有列(即建立索引的字段正好是覆盖查询语句[select子句]与查询条件[Where子句]中所涉及的字段,也即,索引包含了查询正在查找的所有数据)。

 

首先,从聚集索引说起,聚集索引实际上就是一个覆盖索引,在大多数情况下,可以很直观地分辨出数据表的当前聚集索引是否有用,因为聚集索引根据键值字段控制了数据行的顺序。由于SQL SERVER以聚集索引的键值字段来排序数据行,所以当你经常需要对某些字段排序时,把这些要排序的字段作为聚集索引的键值,创建聚集索引将对查询性能会有很大的提升。因为数据已经照聚集索引的键值字段的顺序排序,所以查询执行时不需要额外的排序操作。同时如果使用聚集索引来查找同条记录的其他字段的数据,SQL SERVER也不需要额外地通过指针检索数据,因为在聚集索引找到索引键值的同时就已经找到整条数据。

聚集索引在检索符合某个范围的数据时也很有用。例如,你想要找到所有销售订单编号介于18000-19999的订单,而聚集索引就是通过销售订单编号字段建立的,相近的记录全部会摆放在一起,则访问的分页当然就比较少,通过聚集索引可快速定位包含起始销售订单编号的行,然后检索表中所有连续的行,直到检索到最后的销售订单号。

聚集索引在检索占总行数比例很大的数据行时也比较有用。

下图是使用聚集索引查找数据的示意图。

 

使用聚集索引的好处在于:

   1)所需要的数据都在子叶层(即数据页),找到正确的索引键值后不需要再利用指针做额外的查找

   2SQL SERVER将符合相同条件的数据集中放在一起

 

其次,非聚集索引。非聚集索引结构如下图。

 

如果想要使建立的非聚集索引同时具备以上两种好处,那就要建立非聚集覆盖索引。通过覆盖索引,所有查询想要的数据字段都是索引键值的一部分,而存放在索引的子叶层级。覆盖索引不仅仅只包含你写在WHERE条件内的字段,而且还包含所有SELECT 需要的字段,以及在GROUP BY ORDER BY 子句内的字段。

例:

Select <字段A,B....> from <数据表 T>  where <条件字段C>

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引擎可能不会执行上面的第34步,直接从非聚集索引中查找[COP_G_NO]列速度还会快一些,直接从索引的子叶层读取这三列的数值。

posted @ 2012-09-04 22:38  DotNet菜园  阅读(19570)  评论(11编辑  收藏  举报