解析索引中數(shù)據(jù)列順序的選擇問題
在多個列上面建立索引的時候，我們常常會遇到這樣的一個問題“需要把哪個列放在前面”，因為索引中列順序的不同，會對索引的使用，以至性能產(chǎn)生很大的影響。我們本篇就來分析這個問題。
對于上面的問題，一個常見的回答就是“把選擇性***列放在前面”，這里為了使得后面的講述順序進行，我們先來解釋一下選擇性的含義。選擇性是用來描述數(shù)據(jù)的差異情況的，例如，如果一個表中有1000條數(shù)據(jù)，其中的某個字段，如ID，如果每一條數(shù)據(jù)的ID值都不一樣，那么ID的選擇性就是1；如果其中有300百個ID是一樣的，那么就是說，有700個ID不同，那么選擇性就是70%。很顯然，數(shù)據(jù)的選擇性越高，那么在上面建立索引效果就越好。
下面，我們就來解釋一下為什么在多個列上面建立索引的時候需要把選擇性高的列放在最前面。
也許有朋友聽到上面的建議之后，在建立任何基于多個列的索引的時候，都會把表的聚集索引所在的列作為這個多列索引的***個字段。例如，假設現(xiàn)在表中有4個字段，ID,Name,Age，BirthDate，其中ID是主鍵，也是聚集索引，現(xiàn)在我們需要在Name,BirthDate上面建立索引，這個時候，有朋友發(fā)現(xiàn)：ID的選擇性***，那么把ID放在新的索引中，勢必會更好，于是一個名字為IX_Index的索引就包含了三個列：ID,Name，BirthDate。到后來，可能就發(fā)現(xiàn)，如果冒冒然的這樣做，使得這個新建的索引沒有發(fā)揮作用，反而導致性能問題。
對于數(shù)據(jù)庫中的每一個索引，都會有相應的統(tǒng)計數(shù)據(jù)信息，這個統(tǒng)計數(shù)據(jù)顯示了數(shù)據(jù)的分布情況，統(tǒng)計信息以一個類似柱形的形式表現(xiàn)了數(shù)據(jù)的分布。數(shù)據(jù)庫只把索引中的***個列的數(shù)據(jù)分布情況放在柱形圖中，換句話說，這個統(tǒng)計信息顯示的就是索引中的***個數(shù)據(jù)列的數(shù)據(jù)分布情況（這里面涉及到的內(nèi)容有點深，大家可以關注本站點的“查詢優(yōu)化器內(nèi)核系列”，里面會講述到）。
我給大家看個例子吧，假設在SalesOrderDetail表上面有一個索引：X_SalesOrderDetail_ProductID，運行下面的語句：
這個索引包含的列有：ProductID，SalesOrderID和SalesOrderDetailID。我們查看它的數(shù)據(jù)的柱形分布圖，如下：
我們發(fā)現(xiàn)，其中的RANGE_HI_KEY列出的就是ProductID的值，通過圖中，我們可以知道：ProductID值為826的數(shù)據(jù)有305條，值為831的數(shù)據(jù)有198條。ProductID的值在826到831之間的數(shù)據(jù)有110條。查詢優(yōu)化器就是根據(jù)這個來估算數(shù)據(jù)的條數(shù)的。
通過上面可以知道：把索引中的哪個列放在前面至關重要，如果把一個選擇性很低的列放在前面，那么就導致索引的統(tǒng)計數(shù)據(jù)顯示的數(shù)據(jù)分布完全改變，可能導致查詢優(yōu)化器選擇比較低效的執(zhí)行計劃。
下面，我們就通過一個例子來進一步的看看這個問題。
首先，建立一個測試的表，如下：
這個表中有10000條數(shù)據(jù)，并且這個表是一個堆表，即沒有聚集索引的表。并且在這個表中有100個不同的SomeString值，有5000個不同的SomeDate值，而ID是唯一的，全部都不同。
那么，上面的值的選擇性如下：
|
字段名 |
選擇性 |
|
ID |
100% |
|
SomeString |
100/10000*100%=1% |
|
SomeDate |
5000/10000*100%=50% |
在表中，有一個非聚集索引，假設名字為Idx_test，包含了表中的三個值，三個列在索引中的順序為：ID,SomeDate，SomeString，按照選擇性排序，確實不錯！
- … WHERE ID = @ID AND SomeDate = @dt AND SomeString = @str
- … WHERE ID = @ID AND SomeDate = @dt
- … WHERE ID = @ID
換句話說，就是這個索引只在查詢中的Where/Join的列按照索引中的列的順序使用的時候才有效。如果查詢是這樣的，如下：
對于上面的索引，只有在類似下面的查詢結(jié)構(gòu)中發(fā)揮作用，如下：
- … WHERE SomeDate = @dt或者… SomeDate = @dt AND SomeString = @str
那么，這個索引就不會上面的查詢中使用了，那么查詢在執(zhí)行的時候就會掃描整表了。
我們通過執(zhí)行計劃來看看是不是這樣的。
對于，WHERE ID = @ID的查詢，執(zhí)行計劃如下：
很顯然，執(zhí)行了Seek操作，是很快的。
對于WHERE ID = @ID AND SomeDate = @dt的查詢，執(zhí)行計劃如下：
還是進行了Seek操作。
那么對于… SomeDate = @dt AND SomeString = @str的查詢，如下：
大家可以看到，這個時候已經(jīng)開始進行全表掃描了。
我們本篇講述了在索引的進行列的相等操作時候，列的順序問題，我們下一篇就講述如果是在列上進行不等操作，例如ID>1，那么索引中的列的順序還是這樣進行嗎？
原文鏈接：http://www.cnblogs.com/yanyangtian/archive/2012/05/03/2480052.html
【編輯推薦】
