SQLServer索引密度的实际操作

以下的文章主要向大家描述的是SQL Server索引密度（Index Densities），在实际操作中当一个查询的SARG 的值直到查询运行时才已知，或是 SARG 是关于一个索引的多列时，SQL Server才使用为索引中每列存储的密度值。

对于组合键值，SQL Server为第一列的组合键存储了密度值；为第一列和第二列；为第一、二、三列；等等。这些信息可以从Listing34.1的DBCC SHOW_STATISTICS 输出信息的All density区域看到。

SQL Server索引密度表示为键的唯一键值的倒数。每个键的密度可以按照下面的公式进行计算：

引用

 
 
 
  
  
  Key density = 1.00/ ( Count of distinct key values in the table)

键密度 = 1.00 / （表中的不同键值数）

所以，pubs数据库的author表中state列的密度计算公式如下：

 
 
 
  
  
  Sql代码     
  
  Select Density = 1.00/ (select count (distinct state) from authors)     
  
  Go     
  
  Select Density = 1.00/ (select count (distinct state) from authors)    
  
  Go    
  
  Density     
  
  .1250000000000

State和zip的组合列密度计算如下：

 
 
 
  
  
  Sql代码     
  
  Select density = 1.00/( select count (distinct state + zip) from authors)     
  
  Go     
  
  Select density = 1.00/( select count (distinct state + zip) from authors)    
  
  Go    
  
  Density     
  
  .0555555555555

注意，不像选择率，越小的SQL Server索引密度意味着具有更高的索引选择性。当密度趋近于1，索引就变得有更少的选择性，基本上没有用处了。当索引的选择性低的时候，优化器可能会选择一个表扫描（table scan），或者叶子级的索引扫描（Index scan），而不会进行索引查找（index seek），因为这样会付出更多的代价。

引用

提示：

当心你的数据库中低选择性的索引。这样的索引通常是对系统的性能是一个损害。它们通常不仅不会用来进行数据的检索，而且也会使得数据修改语句变得缓慢，因为需要额外的索引维护。识别这些索引，考虑删除掉它们。

通常，当你给键中添加更多的列时，密度值应该变得更小。例如，在Listing 34.2，密度值逐渐变小。

 
 
 
  
  
  Key Column Index Density     
  
  title_id 1.8621974E-3     
  
  title_id, stor_id 5.997505E-6     
  
  title_id, stor_id, ord_num 5.9268041E-6

使用索引密度评估行数（Estimating Rows Using the Index Statistics）

那么优化器是如何使用SQL Server索引密度来决定一个索引的效果呢？

当在一个范围内查找一个索引值或者键中存在重复值时，SQL Server会使用直方图信息。考虑下面关于bigpubs2000数据库中的sales表中查询：

Sql代码

 
 
 
  
  
  Select * from sales     
  
  Where title_id = 'BI2184'     
  
  Select * from sales    
  
  Where title_id = 'BI2184'

因为在表中title_id中存在重复值，SQL Server使用关于title_id的直方图（参考Listing34.2）来估计匹配的行数。对于BI2184值，它将查看EQ_ROWS值，值为343.0。这表示在表中title_id值为BI2184的记录共有343行。

当一个查询参数（search argument）的精确匹配（exact match 即等号计算）在直方图中step没有发现时，SQL Server使用比查找值（search value）大的下一个step中的AVG_RANG_ROWS值。例如，SQL Server对查找值为‘BI2187’进行评估，它将会发现匹配值为270.0行。

对一个范围检索，SQL Server把检范围两端的RANG_ROW和EQ_ROWS相加。例如，利用Listing34.2中的直方图，如果查找参数为 where title_id <= 'BI2574',行数估计将是：

314 + 613 + 343 + 270 + 277，或者为1817。

当直方图不能使用时，SQL Server就使用索引密度来估计匹配行数。对于等值查找的计算公式是直截了当的，例如：

 
 
 
  
  
  Sql代码     
  
  Declare @tid varchar(6)     
  
  Select @tid = 'BI2574'     
  
  Select count(*) from sales where title_id = @tid     
  
  Declare @tid varchar(6)    
  
  Select @tid = 'BI2574'   
  
  Select count(*) from sales where title_id = @tid

行估计值等于指定键值的SQL Server索引密度（1.8621974E-3）乘以表中行数：

 
 
 
  
  
  Sql代码     
  
  Select count(*) * 1.8621974E-3     
  
  From sales     
  
  Go     
  
  Select count(*) * 1.8621974E-3    
  
  From sales    
  
  Go    
  
  314.19925631500001

如果一个查询的SARG为title_id 和stor_id，并且假如title_id的SARG是一个可在优化期间可评价的常量表达式，SQL Server会用title_id stor_id的索引密度和title_id的直方图来估计匹配的行数（对某些值来说，索引密度估计的值可能会大学直方图估计出来的值）。SQL Server 将会用二者中较小的值作为匹配的行数。

根据title_id stor_id的索引密度，你能看到：

 
 
 
  
  
  Sql代码     
  
  Select coun(*) * 5.997505E-6     
  
  From sales     
  
  Select coun(*) * 5.997505E-6    
  
  From sales    
  
  1.011929031125

在这个例子中，SQL Server将用title_id 和stor_id的SQL Server索引密度来估计匹配的值。在此情况下，它估计查询将返回一条匹配的行。

网站标题：SQLServer索引密度的实际操作
文章来源：http://www.csdahua.cn/qtweb/news46/352596.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：快上网

成都快上网为您推荐相关内容