以下的文章主要向大家描述的是SQL Server索引密度（Index Densities），在實(shí)際操作中當(dāng)一個(gè)查詢(xún)的SARG 的值直到查詢(xún)運(yùn)行時(shí)才已知，或是 SARG 是關(guān)于一個(gè)索引的多列時(shí)，SQL Server才使用為索引中每列存儲(chǔ)的密度值。

對(duì)于組合鍵值，SQL Server為第一列的組合鍵存儲(chǔ)了密度值；為第一列和第二列；為第一、二、三列；等等。這些信息可以從Listing34.1的DBCC SHOW_STATISTICS 輸出信息的All density區(qū)域看到。

SQL Server索引密度表示為鍵的唯一鍵值的倒數(shù)。每個(gè)鍵的密度可以按照下面的公式進(jìn)行計(jì)算：

引用

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

鍵密度 = 1.00 / （表中的不同鍵值數(shù)）

所以，pubs數(shù)據(jù)庫(kù)的author表中state列的密度計(jì)算公式如下：

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的組合列密度計(jì)算如下：

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索引密度意味著具有更高的索引選擇性。當(dāng)密度趨近于1，索引就變得有更少的選擇性，基本上沒(méi)有用處了。當(dāng)索引的選擇性低的時(shí)候，優(yōu)化器可能會(huì)選擇一個(gè)表掃描（table scan），或者葉子級(jí)的索引掃描（Index scan），而不會(huì)進(jìn)行索引查找（index seek），因?yàn)檫@樣會(huì)付出更多的代價(jià)。

引用

提示：

當(dāng)心你的數(shù)據(jù)庫(kù)中低選擇性的索引。這樣的索引通常是對(duì)系統(tǒng)的性能是一個(gè)損害。它們通常不僅不會(huì)用來(lái)進(jìn)行數(shù)據(jù)的檢索，而且也會(huì)使得數(shù)據(jù)修改語(yǔ)句變得緩慢，因?yàn)樾枰~外的索引維護(hù)。識(shí)別這些索引，考慮刪除掉它們。

通常，當(dāng)你給鍵中添加更多的列時(shí)，密度值應(yīng)該變得更小。例如，在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  

使用索引密度評(píng)估行數(shù)（Estimating Rows Using the Index Statistics）

那么優(yōu)化器是如何使用SQL Server索引密度來(lái)決定一個(gè)索引的效果呢？

當(dāng)在一個(gè)范圍內(nèi)查找一個(gè)索引值或者鍵中存在重復(fù)值時(shí)，SQL Server會(huì)使用直方圖信息?？紤]下面關(guān)于bigpubs2000數(shù)據(jù)庫(kù)中的sales表中查詢(xún)：

Sql代碼

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

因?yàn)樵诒碇衪itle_id中存在重復(fù)值，SQL Server使用關(guān)于title_id的直方圖（參考Listing34.2）來(lái)估計(jì)匹配的行數(shù)。對(duì)于BI2184值，它將查看EQ_ROWS值，值為343.0。這表示在表中title_id值為BI2184的記錄共有343行。

當(dāng)一個(gè)查詢(xún)參數(shù)（search argument）的精確匹配（exact match 即等號(hào)計(jì)算）在直方圖中step沒(méi)有發(fā)現(xiàn)時(shí)，SQL Server使用比查找值（search value）大的下一個(gè)step中的AVG_RANG_ROWS值。例如，SQL Server對(duì)查找值為‘BI2187’進(jìn)行評(píng)估，它將會(huì)發(fā)現(xiàn)匹配值為270.0行。

對(duì)一個(gè)范圍檢索，SQL Server把檢范圍兩端的RANG_ROW和EQ_ROWS相加。例如，利用Listing34.2中的直方圖，如果查找參數(shù)為 where title_id <= 'BI2574',行數(shù)估計(jì)將是：

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

當(dāng)直方圖不能使用時(shí)，SQL Server就使用索引密度來(lái)估計(jì)匹配行數(shù)。對(duì)于等值查找的計(jì)算公式是直截了當(dāng)?shù)?，例如?/p>

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  

行估計(jì)值等于指定鍵值的SQL Server索引密度（1.8621974E-3）乘以表中行數(shù)：

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

如果一個(gè)查詢(xún)的SARG為title_id 和stor_id，并且假如title_id的SARG是一個(gè)可在優(yōu)化期間可評(píng)價(jià)的常量表達(dá)式，SQL Server會(huì)用title_id stor_id的索引密度和title_id的直方圖來(lái)估計(jì)匹配的行數(shù)（對(duì)某些值來(lái)說(shuō)，索引密度估計(jì)的值可能會(huì)大學(xué)直方圖估計(jì)出來(lái)的值）。SQL Server 將會(huì)用二者中較小的值作為匹配的行數(shù)。

根據(jù)title_id stor_id的索引密度，你能看到：

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

在這個(gè)例子中，SQL Server將用title_id 和stor_id的SQL Server索引密度來(lái)估計(jì)匹配的值。在此情況下，它估計(jì)查詢(xún)將返回一條匹配的行。

【編輯推薦】

1. 優(yōu)化SQL Server數(shù)據(jù)庫(kù)的經(jīng)驗(yàn)大盤(pán)點(diǎn)
2. SQL Server 2005商業(yè)智能功能淺析
3. 修改SQL Server 2005 數(shù)據(jù)庫(kù)的執(zhí)行環(huán)境很簡(jiǎn)單
4. SQL Server 2000數(shù)據(jù)庫(kù)備份和還原的示例
5. SQL Server 2008數(shù)據(jù)庫(kù)在實(shí)際應(yīng)用中的獨(dú)到之處