技术开发 频道

SQLSERVER数据访问优化之使用索引

  第二步:创建正确的复合索引

  现在,你是否已经在数据库创建了所有的适合的索引?假设,在一个Sales表(SelesID,SalesDate,SalesPersonID,ProductID,Qty),你已经在外键(ProductID)创建了 索引,如果ProductID是一个高选择性列,任何在where语句里使用索引列(ProductID)的检索数据的SELECT查询都会运行的非常快吗?

  对,相对没有在外键创建索引的情况(这需要全部数据页的遍历) 来说,这是非常快的,但是,还有进一步提升的空间.

  让我们假设:Sales表包含10,000行数据,下面的SQL语句选择400行。

  SELECT SalesDate, SalesPersonID FROM Sales WHERE ProductID = 112

  首先让我们弄明白在数据库引擎怎么执行SQL语句的:

  1. Sales表有在ProductID列一个非聚焦索引,所以,首先查询非聚焦索引树,发现包含ProductID=112 的入口。

  2. 包含ProductID = 112入口的索引页同样同样也包含了聚焦索引的值(所有的主健的值 ,即SalesID )

  3. 对于每一个主健(共400个),数据库引擎进入聚焦索引树来发现正确的行的位置

  4. 对于每一个主健,一旦发现正确的行的位置,数据库引擎会从匹配的行得到SalesDate 和 SalesPersonID的列的值。

  请注意,在上述的步骤中,对于每一个ProductID = 112的主键入口(共400个),数据库引擎必须搜索聚焦索引树400次,来检索附加的列(SalesDate, SalesPersonID)。

  让我们猜想一下, 如果非聚焦索引不但包含了聚焦索引的值(主健),同时还包含查询里标注的其他的2个列(SalesDate, SalesPersonID)的值,数据库引擎就不用执行上述的第3步和第4步,只须进入ProductID的列的非聚焦索引树,从索引页上读取3个列的值,这样运行的速度不是更快吗?

  幸运的是,有一种办法来实施这种特点,这就是复合索引。你可以在表的列上创建复合索引,标明哪些列是和聚焦索引一起的应该附加存储的列。下面是一个在表Sales表的列ProductID创建复合索引的例子。

  CREATE INDEX NCLIX_Sales_ProductID--Index name

  ON dbo.Sales(ProductID)--Column on which index is to be created

  INCLUDE(SalesDate, SalesPersonID)--Additional column values to include

  请注意,创建复合索引应当包含少数几个列,并且这些列经常在select查询里使用。在复合索引里包含太多的列不仅不会给你带来太多好处。而且由于使用相当多的内存来存储复合索引的列的值,其后果是内存溢出和性能降低。

  当创建复合索引的时候,尽量使用Database Tuning Advisor(数据库优化顾问)的帮助。

  我们知道,一旦一个SQL开始运行,SQL SERVER 引擎优化器基于以下几点动态的产生不同的检索计划。

   数据量

   统计

   索引变化

   TSQL的参数值

   服务器的负载

  这意味着:对于一个特殊的SQL语句,在产品服务器上的执行计划可能和在测试服务器上的执行计划不近相同,甚至表和索引结构一样。这同样也表明,一个在测试服务器上创建的索引可能会加速测试服务器上的性能,但是在产品服务器上的同样的索引可能不会带给你任何益处。为什么?因为在测试环境下的SQL SEVVER执行计划可能使用创建的索引,因此给你很好的性能,但是,在产品服务器上的执行计划可能出于下列的原因而根本不使用新创建的索引。例如:一个非聚焦索引列在产品服务器上不是高选择性列,而在测试服务器上是高选择性列.

  所以,当创建索引的时候,我们需要弄明白这一点:索引是执行引擎用来提高速度的。但是我们该如何去做呢?

  答案是我们必须在测试服务器上模拟产品服务器的负载,接着创建索引,以及测试他们。只有这样,在测试服务器上能提高性能的索引,才能更有可能在产品服务器上提高性能。

  这么做应该很困难,但幸运的是,我们有一些好用的工具去实现它,请跟随下面的指导:

  1:使用SQL profiler捕获产品服务器上的痕迹。使用Tuning template(我知道,有人建议不要在产品服务器上使用SQL profiler,但有些时候,你不得不在产品服务器上诊断性能问题的时候使用它),如果你不熟悉这个工具,或者你想了解更多的关于SQL profiler的知识,请阅读http://msdn.microsoft.com/en-us/library/ms181091.aspx

  2.利用上一步产生的跟踪文件,用数据库优化顾问在测试数据库创建相似的负载,从优化顾问得到一些建议,特别是创建索引的建议,你很可能从优化顾问那里获得比较实际的建议。因为优化顾问使用产品服务器产生的跟踪文件来装载测试服务器,所以能产生最可能好的索引建议。如果你不熟悉优化顾问工具,或者你想了解更多的关于使用优化顾问的的资料,请阅读:http://msdn.microsoft.com/en-us/library/ms166575.aspx.

0
相关文章