解析索引中數據列順序的選擇問題
在多個列上面建立索引的時候，我們常常會遇到這樣的一個問題“需要把哪個列放在前面”，因為索引中列順序的不同，會對索引的使用，以至性能產生很大的影響。我們本篇就來分析這個問題。
對於上面的問題，一個常見的回答就是“把選擇性最大列放在前面”，這里為了使得后面的講述順序進行，我們先來解釋一下選擇性的含義。選擇性是用來描述數據的差異情況的，例如，如果一個表中有1000條數據，其中的某個字段，如ID，如果每一條數據的ID值都不一樣，那么ID的選擇性就是1；如果其中有300百個ID是一樣的，那么就是說，有700個ID不同，那么選擇性就是70%。很顯然，數據的選擇性越高，那么在上面建立索引效果就越好。
下面，我們就來解釋一下為什么在多個列上面建立索引的時候需要把選擇性高的列放在最前面。
也許有朋友聽到上面的建議之后，在建立任何基於多個列的索引的時候，都會把表的聚集索引所在的列作為這個多列索引的第一個字段。例如，假設現在表中有4個字段，ID,Name,Age，BirthDate，其中ID是主鍵，也是聚集索引，現在我們需要在Name,BirthDate上面建立索引，這個時候，有朋友發現：ID的選擇性最高，那么把ID放在新的索引中，勢必會更好，於是一個名字為IX_Index的索引就包含了三個列：ID,Name，BirthDate。到后來，可能就發現，如果冒冒然的這樣做，使得這個新建的索引沒有發揮作用，反而導致性能問題。
對於數據庫中的每一個索引，都會有相應的統計數據信息，這個統計數據顯示了數據的分布情況，統計信息以一個類似柱形的形式表現了數據的分布。數據庫只把索引中的第一個列的數據分布情況放在柱形圖中，換句話說，這個統計信息顯示的就是索引中的第一個數據列的數據分布情況（這里面涉及到的內容有點深，大家可以關注本站點的“查詢優化器內核系列”，里面會講述到）。
我給大家看個例子吧，假設在SalesOrderDetail表上面有一個索引：X_SalesOrderDetail_ProductID，運行下面的語句：
這個索引包含的列有：ProductID，SalesOrderID和SalesOrderDetailID。我們查看它的數據的柱形分布圖，如下：
我們發現，其中的RANGE_HI_KEY列出的就是ProductID的值，通過圖中，我們可以知道：ProductID值為826的數據有305條，值為831的數據有198條。ProductID的值在826到831之間的數據有110條。查詢優化器就是根據這個來估算數據的條數的。
通過上面可以知道：把索引中的哪個列放在前面至關重要，如果把一個選擇性很低的列放在前面，那么就導致索引的統計數據顯示的數據分布完全改變，可能導致查詢優化器選擇比較低效的執行計划。
下面，我們就通過一個例子來進一步的看看這個問題。
首先，建立一個測試的表，如下：
這個表中有10000條數據，並且這個表是一個堆表，即沒有聚集索引的表。並且在這個表中有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的列按照索引中的列的順序使用的時候才有效。如果查詢是這樣的，如下：
… WHERE SomeDate = @dt或者… SomeDate = @dt AND SomeString = @str
那么，這個索引就不會上面的查詢中使用了，那么查詢在執行的時候就會掃描整表了。
我們通過執行計划來看看是不是這樣的。
對於，WHERE ID = @ID的查詢，執行計划如下：
很顯然，執行了Seek操作，是很快的。
對於WHERE ID = @ID AND SomeDate = @dt的查詢，執行計划如下：
還是進行了Seek操作。
那么對於… SomeDate = @dt AND SomeString = @str的查詢，如下：
大家可以看到，這個時候已經開始進行全表掃描了。
我們本篇講述了在索引的進行列的相等操作時候，列的順序問題，我們下一篇就講述如果是在列上進行不等操作，例如ID>1，那么索引中的列的順序還是這樣進行嗎？
系列文章鏈接：
IIS負載均衡-Application Request Route詳解第一篇： ARR介紹
IIS負載均衡-Application Request Route詳解第二篇：創建與配置Server Farm
IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（上）
IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（下）
IIS負載均衡-Application Request Route詳解第四篇：使用ARR實現三層部署架構
負載均衡原理與實踐詳解 第三篇 服務器負載均衡的基本概念-網絡基礎
負載均衡原理與實踐詳解 第九篇 服務器負載均衡技術進階-會話保持（上）
負載均衡原理與實踐詳解 第十篇 服務器負載均衡技術進階-會話保持（中）
負載均衡原理與實踐詳解 第十一篇 服務器負載均衡技術進階-會話保持（下） 之：延遲綁定