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

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

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

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

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

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

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

2)SQL 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引擎可能不会执行上面的第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)

   
   

SQL Server 查询性能优化——覆盖索引的更多相关文章

  1. SQL Server查询性能优化——覆盖索引(二)

    在SQL Server 查询性能优化——覆盖索引(一)中讲了覆盖索引的一些理论. 本文将具体讲一下使用不同索引对查询性能的影响. 下面通过实例,来查看不同的索引结构,如聚集索引.非聚集索引.组合索引等 ...

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

    覆盖索引又可以称为索引覆盖. 解释一: 就是select的数据列只用从索引中就能够取得,不必从数据表中读取,换句话说查询列要被所使用的索引覆盖. 解释二: 索引是高效找到行的一个方法,当能通过检索索引 ...

  3. SQL Server查询性能优化——创建索引原则(一)

    索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页 就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索 ...

  4. SQL Server 查询性能优化——创建索引原则(一)(转载)

    索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索引 ...

  5. SQL Server 查询性能优化——创建索引原则(一)

    索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索引 ...

  6. SQL Server 查询性能优化——创建索引原则

    索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索引 ...

  7. SQL Server 查询性能优化——创建索引原则(二)

    三:索引的建立原则 一般来说,建立索引要看数据使用的场景,换句话来说哪些访问数据的SQL语句是常用的,而这些语句是否因为缺少索引(也有可能是索引过多)变的效率低下.但绝不是所有的SQL语句都要建立索引 ...

  8. SQL SERVER 查询性能优化——分析事务与锁(五)

    SQL SERVER 查询性能优化——分析事务与锁(一) SQL SERVER 查询性能优化——分析事务与锁(二) SQL SERVER 查询性能优化——分析事务与锁(三) 上接SQL SERVER ...

  9. SQL Server 查询性能优化 相关文章

    来自: SQL Server 查询性能优化——堆表.碎片与索引(一) SQL Server 查询性能优化——堆表.碎片与索引(二) SQL Server 查询性能优化——覆盖索引(一) SQL Ser ...

随机推荐

  1. HDU 5074 Hatsune Miku(2014鞍山赛区现场赛E题)

    题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=5074 解题报告:给出一个长度为n的序列,例如a1,a2,a3,a4......an,然后这个序列的美丽 ...

  2. 项目如何脱离TFS 2010的管理

    在VS 里,文件->源代码管理->更改源代码管理->取消绑定.

  3. Python中的日志管理Logging模块

    1.基本的用法 import logging logging.debug('This is debug message') logging.info('This is info message') l ...

  4. php简单缓存类

    <?phpclass Cache {    private $cache_path;//path for the cache    private $cache_expire;//seconds ...

  5. 委托、匿名委托和lambda表达式

    1.委托 在.NET中,委托有点类似于C/C++中的函数指针,但与指针不同的是,委托是一种安全的类型,那么我们就以实现两个数的差为例,先声明一个成员方法: public int CompareTwoV ...

  6. Android 获取当前日期算前一年、前一月、前一天Calendar

    使用Calendar的add(int field, int amount)方法 Calendar ca = Calendar.getInstance();//得到一个Calendar的实例 ca.se ...

  7. WinDBG调试.NET程序示例

    WinDBG调试.NET程序示例 好不容易把环境打好了,一定要试试牛刀.我创建了一个极其简单的程序(如下).让我们期待会有好的结果吧,阿门! using System; using System.Co ...

  8. textview设置不同字体大小

    <style name="style0"> <item name="android:textSize">19dip</item&g ...

  9. pci设备驱动相关

    pci 设备注册及查找: https://www.cnblogs.com/image-eye/archive/2012/02/15/2352912.html PFN https://nieyong.g ...

  10. ExecutorService——&lt;T&gt; Future&lt;T&gt; submit(Callable&lt;T&gt; task)

    提交一个有返回值的任务用于执行,且返回一个Future对象,用来表示行将发生的任务的结果. 如果任务执行成功的话,那么Future对象的get方法将会返回任务的执行结果T.   如果你想要立即阻塞,等 ...