SQL Server索引密度的实际操作

数据库 SQL Server
我们今天主要向大家讲述的是SQL Server索引密度(Index Densities),以及对其实际操作中要用到的代码描述。以下就是正文的主要内容描述。

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

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

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

 

 

引用

 

 

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

 

键密度 = 1.00 / (表中的不同键值数)

 

 

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

 

 

  1. Sql代码   
  2. Select Density = 1.00/ (select count (distinct state) from authors)   
  3. Go   
  4. Select Density = 1.00/ (select count (distinct state) from authors)  
  5. Go  
  6. Density   
  7. .1250000000000   
  8.  

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

  1. Sql代码   
  2. Select density = 1.00/( select count (distinct state + zip) from authors)   
  3. Go   
  4. Select density = 1.00/( select count (distinct state + zip) from authors)  
  5. Go  
  6. Density   
  7. .0555555555555   
  8.  

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

 

引用

 

提示:

 

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

 

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

 

 

  1. Key Column Index Density   
  2. title_id 1.8621974E-3   
  3. title_id, stor_id 5.997505E-6   
  4. title_id, stor_id, ord_num 5.9268041E-6  

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

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

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

 

Sql代码

 

  1. Select * from sales   
  2. Where title_id = 'BI2184'   
  3. Select * from sales  
  4. 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就使用索引密度来估计匹配行数。对于等值查找的计算公式是直截了当的,例如:

  1. Sql代码   
  2. Declare @tid varchar(6)   
  3. Select @tid = 'BI2574'   
  4. Select count(*) from sales where title_id = @tid   
  5. Declare @tid varchar(6)  
  6. Select @tid = 'BI2574' 
  7. Select count(*) from sales where title_id = @tid  

 

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

  1. Sql代码   
  2. Select count(*) * 1.8621974E-3   
  3. From sales   
  4. Go   
  5. Select count(*) * 1.8621974E-3  
  6. From sales  
  7. Go  
  8. 314.19925631500001   

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

根据title_id stor_id的索引密度,你能看到:

  1. Sql代码   
  2. Select coun(*) * 5.997505E-6   
  3. From sales   
  4. Select coun(*) * 5.997505E-6  
  5. From sales  
  6. 1.011929031125   

 

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

【编辑推荐】

  1. 优化SQL Server数据库的经验大盘点
  2. SQL Server 2005商业智能功能浅析
  3. 修改SQL Server 2005 数据库的执行环境很简单
  4. SQL Server 2000数据库备份和还原的示例
  5. SQL Server 2008数据库在实际应用中的独到之处
责任编辑:佚名 来源: 重庆晨报
相关推荐

2010-06-17 12:26:51

SQL Server索

2010-07-02 12:51:35

SQL Server

2010-07-21 15:22:07

2010-07-23 09:25:50

SQL Server导

2010-06-28 12:39:14

SQL Server数

2010-07-16 11:10:52

SQL server

2010-06-30 17:56:06

2010-06-28 12:27:35

SQL Server

2010-04-20 11:06:33

Oracle索引

2010-06-28 13:27:33

SQL Server视

2010-07-05 12:21:57

SQL Server记

2010-07-06 09:20:30

SQL Server查

2010-07-12 10:13:44

SQL Server表

2010-06-18 08:30:48

SQL Server

2010-07-02 11:10:56

SQL Server

2010-07-23 14:26:37

SQL Server存

2010-07-21 09:28:34

SQL Server

2010-07-05 10:15:40

SQL Server

2010-07-20 11:13:09

SQL Server日

2010-07-09 12:49:41

SQL Server自
点赞
收藏

51CTO技术栈公众号