包含列的索引:通往SQL Server索引级别5的阶梯

Posted 我是墩

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了包含列的索引:通往SQL Server索引级别5的阶梯相关的知识,希望对你有一定的参考价值。

                                                                包含列的索引:通往SQL Server索引级别5的阶梯

 大卫?杜兰特2011/07/13

 

该系列

本文是楼梯系列的一部分:SQL Server索引的阶梯

索引是数据库设计的基础,并告诉开发人员使用数据库非常了解设计器的意图。不幸的是,当性能问题出现时,索引常常被添加到事后。这里最后是一个简单的系列文章,它应该能让任何数据库专业人员快速“跟上”他们的步伐

前面的级别引入了集群和非聚集索引,突出了每个方面的以下方面::

1.表中的每一行都有一个条目(我们注意到这个规则的例外情况将在以后的级别中被覆盖)。这些条目总是在索引键序列中。

2.在聚集索引中,索引项是表的实际行。

3.在非聚集索引中,条目与数据行分开;并由索引键列和书签值组成,将索引键列映射到表的实际行。

前半句是正确的,但不完整。在这个级别中,我们检查了将附加的列包含到非聚集索引的选项,称为包含列。在第6级检查书签操作时,我们会看到SQL Server可能会单方面向索引添加一些列。

 

包括列

非聚集索引中的列,但不是索引键的一部分,被称为包含列。这些列不是键的一部分,因此不影响索引中的条目序列。而且,正如我们将看到的,它们比键列的开销更少。

在创建非聚集索引时,我们将分别从键列指定包含的列;如清单5.1所示。

CREATE NONCLUSTERED INDEX FK_ProductID_ ModifiedDate

       ON Sales.SalesOrderDetail (ProductID, ModifiedDate)

       INCLUDE (OrderQty, UnitPrice, LineTotal)

 

清单5.1:创建包含列的非聚集索引

在本例中,ProductID和ModifiedDate是索引键列,OrderQty、UnitPrice和LineTotal是包含的列。

如果我们没有在上面的SQL语句中指定INCLUDE子句,那么结果的索引应该是这样的:

ProductID   ModifiedDate书签

N页:

707         2004/07/25        =>  
707         2004/07/26        =>  
707         2004/07/26        =>  
707         2004/07/26        =>  
707         2004/07/27        =>  
707         2004/07/27        =>  
707         2004/07/27        =>  
707         2004/07/28        =>  
707         2004/07/28        =>  
707         2004/07/28        =>  
707         2004/07/28        =>  
707         2004/07/28        =>  
707         2004/07/28        =>  

n+1页:

707         2004/07/29        =>  
707         2004/07/31        =>  
707         2004/07/31        =>  
707         2004/07/31        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  
708         2001/07/01        =>  

 

然而,已经告诉SQL Server包括OrderQty、UnitPrice和LineTotal列,索引看起来是这样的:

:- Search Key Columns -:      :---  Included Columns  ---:     : Bookmark :

ProductID   ModifiedDate      OrderQty    UnitPrice   LineTotal       

Page n-1:

707         2004/07/29        1           34.99       34.99       =>  
707         2004/07/31        1           34.99       34.99       =>  
707         2004/07/31        3           34.99      104.97       =>  
707         2004/07/31        1           34.99       34.99       =>  
708         2001/07/01        5           20.19      100.95       =>  

Page n:

708         2001/07/01        1           20.19       20.19       =>  
708         2001/07/01        1           20.19       20.19       =>  
708         2001/07/01        2           20.19       40.38       =>  
708         2001/07/01        1           20.19       20.19       =>  
708         2001/07/01        2           20.19       40.38       =>  

708         2001/12/01        7           20.19      141.33       =>  
708         2001/12/01        1           20.19       20.19       =>  
708         2002/01/01        1           20.19       20.19       =>  
708         2002/01/01        1           20.19       20.19       =>  
708         2002/01/01        1           20.19       20.19       =>  

Page n+1:

708         2002/01/01        2           20.19       40.38       =>  
708         2002/01/01        5           20.19      100.95       =>  
708         2002/02/01        1           20.19       20.19       =>  
708         2002/02/01        1           20.19       20.19       =>  
708         2002/02/01        2           20.19       40.38       =>  

 

检查这个索引的内容,很明显,这些行是由索引键列排序的。例如,在2002年1月1日修改后的产品708(以粗体显示)的5行,在索引中是连续的,就像其他所有ProductID / ModifiedDate组合中的行一样。

你可能会问“为什么要包含列呢?”为什么不直接向索引键添加OrderQty、UnitPrice和LineTotal ?“在索引中有这些列有几个优点,但索引键没有,比如:

1.不属于索引键的列不会影响索引内条目的位置。这反过来降低了在索引中使用它们的开销。例如,如果行中的ProductID或ModifiedDate值被修改,那么该行的条目必须在索引中重新定位。但是,如果在行中的unit定价evalue被修改,那么索引项仍然需要更新,但它不需要移动。

2.在索引中定位一个条目所需的工作量更少。

3.指数的大小将会稍微小一些。

4.索引的数据分布统计数据将更容易维护。

当我们查看索引的内部结构以及SQL Server维护的一些额外信息以优化查询性能时,这些优势在以后的级别中会更有意义。

决定一个索引列是否是索引键的一部分,或者仅仅是一个包含的列,并不是您所要做的最重要的索引决定。也就是说,在SELECT列表中经常出现的列,而不是查询的WHERE子句中最优的列在索引的列中。

 

成为一种覆盖指数

 

在第4级,我们与AdventureWorksdatabase的设计人员达成协议,他们决定让SalesOrderID / SalesOrderDetailID为SalesOrderDetail表的集群索引。针对此表的大多数查询将请求按销售订单号排序或分组的数据。但是,一些查询,可能来自仓库人员,将需要在产品序列中的信息。这些查询将从清单5.1中显示的索引中获益。

为了说明在该索引中包含包含列的潜在好处,我们将查看针对SalesOrderDetailtable的两个查询,每个查询将执行三次,如下:

1.运行1:没有非聚集索引

2.运行2:使用包含不包含列的非聚集索引(只有两个键列)

3.运行3:使用清单5.1中定义的非聚集索引

正如我们在以前的级别中所做的那样,我们再次使用读作为主要度量,但是我们也使用SQL Server Management Studio的“显示实际执行计划”选项来查看每个执行的计划。这将给我们一个额外的度量:在非读取活动上花费的工作量的百分比,例如在读入内存之后匹配相关数据。这使我们更好地理解了查询的总成本。

 

测试第一个查询:活动总数按产品

我们的第一个查询,如清单5.2所示,是一个为特定产品提供活动总数的查询。

SELECT  ProductID ,

        ModifiedDate ,

        SUM(OrderQty) AS No of Items ,

        AVG(UnitPrice) Avg Price ,

        SUM(LineTotal) Total Value

FROM    Sales.SalesOrderDetail

WHERE   ProductID = 888

GROUP BY ProductID ,

        ModifiedDate ;

 

清单5.2:“产品的活动总数”查询

因为索引可以影响查询的性能,但不能影响结果;针对这三种不同的索引方案执行此查询总是会产生以下行集:

ProductID   ModifiedDate    No of Rows  Avg Price         Total Value

----------- ------------    ----------- -----------------------------
888         2003-07-01      16          602.346           9637.536000
888         2003-08-01      13          602.346           7830.498000
888         2003-09-01      19          602.346           11444.574000
888        2003-10-01       2           602.346           1204.692000
888         2003-11-01      17          602.346           10239.882000
888         2003-12-01      4           602.346           2409.384000
888         2004-05-01      10          602.346           6023.460000
888         2004-06-01      2           602.346           1204.692000

 

8行输出从表中的39个“ProductID = 888”行聚合到每个有一个或多个“ProductID = 888”销售的日期的输出行。进行测试的基本方案如清单5.3所示。在运行任何查询之前,确保运行SET STATISTICS IO ON。

IF EXISTS ( SELECT  1

            FROM    sys.indexes

            WHERE   name = FK_ProductID_ModifiedDate

                    AND OBJECT_ID = OBJECT_ID(Sales.SalesOrderDetail) ) 

    DROP INDEX Sales.SalesOrderDetail.FK_ProductID_ModifiedDate ;

GO

 

 

-- 运行1:在这里执行清单5.2(没有非聚集索引)
 
CREATE NONCLUSTERED INDEX FK_ProductID_ModifiedDate

ON Sales.SalesOrderDetail (ProductID, ModifiedDate) ;

 

 

 

--运行2:在这里重新执行清单5.2(非集群索引,不包含任何内容)
 
IF EXISTS ( SELECT  1

            FROM    sys.indexes

            WHERE   name = FK_ProductID_ModifiedDate

                    AND OBJECT_ID = OBJECT_ID(Sales.SalesOrderDetail) ) 

    DROP INDEX Sales.SalesOrderDetail.FK_ProductID_ModifiedDate ;

GO

 

CREATE NONCLUSTERED INDEX FK_ProductID_ModifiedDate

ON Sales.SalesOrderDetail (ProductID, ModifiedDate)

INCLUDE (OrderQty, UnitPrice, LineTotal) ;
--运行3:在这里重新执行清单5.2(包含包含的非聚集索引)
 
清单5.3:测试“产品的活动总数”查询
对每个索引方案执行查询所需的相对工作如表5.1所示。

运行1:

没有非聚集索引

表“SalesOrderDetail”。扫描计数1,逻辑读1238。

非阅读活动:8%。

运行2:

索引-不包括列

表“SalesOrderDetail”。扫描计数1,逻辑读131。

非阅读活动:0%。

运行3:

包括列

表“SalesOrderDetail”。扫描计数1,逻辑读3。

非阅读活动:1%。

 
表5.1:使用不同的非聚集索引运行第一个查询的结果三次
 
从这些结果可以看出:
1.运行1需要对SalesOrderDetail表进行完整的扫描;每一行都必须阅读和检查,以确定是否应该参与结果。
2.Run 2使用非聚集索引快速查找39个请求行的书签,但它必须从表中逐个检索这些行。
3.运行3在非聚集索引中找到所需的所有内容,并在ProductID内最有利的序列中进行修改。它迅速跳到第一个请求的条目,读了39个连续的条目,在读取的每个条目上做汇总计算,然后完成了。

测试第二个查询:基于日期的活动总数
我们的第二个查询与第一个查询完全相同,只是在WHERE子句中发生了更改。这一次,仓库是根据日期请求信息,而不是基于产品。我们必须在最右的搜索键栏上进行过滤,修改日期;而不是最左边的列,ProductID。新的查询如清单5.4所示。
SELECT  ModifiedDate ,

        ProductID ,

        SUM(OrderQty) No of Items ,

        AVG(UnitPrice) Avg Price ,

        SUM(LineTotal) Total Value

FROM    Sales.SalesOrderDetail

WHERE   ModifiedDate = 2003-10-01

GROUP BY ModifiedDate ,

        ProductID ;

 

 

 

清单5.4:“按日期执行的活动总数”查询
产生的行集,部分是:
ProductID   ModifiedDate    No of Items Avg Price             Total Value
----------- ------------    ----------- --------------------- ----------------
                                   :
                                   :
782         2003-10-01      62          1430.9937             86291.624000
783         2003-10-01      72          1427.9937             100061.564000
784         2003-10-01      52          1376.994              71603.688000
792         2003-10-01      12          1466.01               17592.120000
793         2003-10-01      46          1466.01               67436.460000
794         2003-10-01      37          1466.01               54242.370000
795         2003-10-01      22          1466.01               32252.220000
                                   :
                                   :
(164 row(s) affected)
 
 
WHERE子句将表过滤到1492行;在分组时,生成了164行输出。
 
要运行测试,请遵循清单5.3中描述的相同方案,但是使用清单5.4中的新查询。结果是针对每个索引方案执行查询所需的相对工作,如表5.2所示。

运行1:

没有非聚集索引

表“SalesOrderDetail”。扫描计数1,逻辑读1238。

非阅读活动:10%。

运行 2:

索引-不包括列

表“SalesOrderDetail”。扫描计数1,逻辑读1238。

非阅读活动:10%。

运行3:

包括列

表“SalesOrderDetail”。扫描计数1,逻辑读761。

非阅读活动:8%。

 
表2:使用不同的非聚集索引运行第二个查询的结果
 
第一次和第二次测试都产生了相同的计划;一个完整的扫描详细信息表。由于第4级中详细讨论的原因,WHERE子句没有足够的选择性从非覆盖索引中获益。而且,包含任何一个组的行分布在整个表中。在读取表时,每一行必须与组相匹配;以及消耗处理器时间和内存的操作。
第三个测试在非聚集索引中找到了它所需要的一切;但是,与前面的查询不同,它没有发现索引中相邻的行。在索引中,包含每个组的行是连续的;但这些组织本身分散在指数的长度上。因此,SQL Server扫描索引。
1.扫描索引而不是表格有两个优点:
2.该指数小于表,要求更少的读数。
3.这些行已经分组,需要更少的非读活动。
总结
包含的列使非聚集索引能够成为各种查询的索引,从而提高这些查询的性能;有时会很显著。包含的列增加了索引的大小,但在开销方面却没有增加。任何时候创建非聚集索引,尤其是在外键列上,都要问自己:“在这个索引中应该包含哪些额外的列?”
 
链接:http://www.sqlservercentral.com/articles/Stairway+Series/72276/
































































以上是关于包含列的索引:通往SQL Server索引级别5的阶梯的主要内容,如果未能解决你的问题,请参考以下文章

包含列的索引:SQL Server索引的阶梯级别5

包含列的 SQL Server 索引 - 转换为 Oracle

[转帖]SQL Server 索引中include的魅力(具有包含性列的索引)

SQL Server 索引中include的魅力(具有包含性列的索引)

具有许多包含列的 SQL Server 范围索引

Sql Server关于create index include带有包含列的索引