詳解SQL Server非叢集索引(ZZ)

在SQL SERVER中，非叢集索引其實可以看作是一個含有叢集索引的表.但相比實際的表而言.非叢集索引中所儲存的表的列數要窄很多，因為非叢集索引僅僅包含原表中非叢集索引的列和指向實際物理表的指標。

　　並且，對於非叢集索引表來說，其中所存放的列是按照叢集索引來進行存放的.所以尋找速度要快了很多。但是對於效能的榨取來說，SQL SERVER總是竭盡所能，假如僅僅是通過索引就可以在B樹的葉子節點擷取所需資料，而不再用通過葉子節點上的指標去尋找實際的物理表,那效能的提升將會更勝一籌.

　　下面我們來看下實現這一點的幾種方式.

　　非叢集索引的覆蓋

　　正如前面簡介所說。非叢集索引其實可以看作一個叢集索引表.當這個非叢集索引中包含了查詢所需要的所有資訊時，則查詢不再需要去查詢基本表，而僅僅是從非叢集索引就能得到資料:

　　下面來看非叢集索引如何覆蓋的:

　　在adventureWorks的SalesOrderHeader表中，現在只有CustomerID列有非叢集索引，而BillToAddressID沒有索引，我們的查詢計劃會是這樣:

　　查詢會根據CustomerID列上的非叢集索引找到相應的指標後，去基本表上尋找資料.從執行計畫可以想象，這個效率並不快。

　　下面我們來看覆蓋索引，通過在CustomerID和BillToAddressID上建立非叢集索引，我們覆蓋到了上面查詢語句的所有資料:

　　通過覆蓋索引，可以看到執行計畫簡單到不能再簡單，直接從非叢集索引的葉子節點提取到資料，無需再掃描基本表!

　　這個效能的提升可以從IO統計看出來,下面我們來看有覆蓋索引和沒有覆蓋索引的IO對比:

　　索引的覆蓋不僅僅帶來的是效率的提升，還有並發的提升，因為減少了對基本表的依賴，所以提升了並發，從而減少了死結!

　　理解INCLUDE的魔力

　　上面的索引覆蓋所帶來的效率提升就像魔術一樣，但別著急，正如我通篇強調的一樣，everything has price.如果一個索引包含了太多的鍵的話，也會帶來很多副作用。INCLUDE的作用使得非叢集索引中可以包含更多的列，但不作為“鍵”使用。

　　比如:假設我們上面的那個查詢需要增加一列，則原來建立的索引無法進行覆蓋，從而還需要尋找基本表:

　　但是如果要包含SubTotal這個總金額，則索引顯得太寬，因為我們的業務很少根據訂單價格作為查詢條件,則使用INCLUDE建立索引:

 

　　理解INCLUDE包含的列和索引建立的列可以這樣理解,把上述建立的含有INCLUDE的非叢集索引想像成:

　　使用INCLUDE可以減少葉子“鍵”的大小!

　　非叢集索引的交叉

　　非叢集索引的交叉看以看作是覆蓋索引的擴充!

　　由於很多原因，比如：

　　在生產環境中，我們往往不能像上面建立覆蓋索引那樣隨意改動現有索引，這可能導致的結果是你會更頻繁的被客戶打電話“關照”

　　現有的非叢集索引已經很“寬”，你如果繼續拓寬則增改查帶來的效能下降的成本會高過提高查詢帶來的好處

　　這時候，你可以通過額外建立索引。正如我前面提到的，非叢集索引的本質是表，通過額外建立表使得幾個非叢集索引之間進行像表一樣的Join,從而使非叢集索引之間可以進行Join來在不訪問基本表的情況下給查詢最佳化工具提供所需要的資料:

　　比如還是上面的那個例子.我們需要查取SalesOrderHeader表,通過BillToAddressID,CustomerID作為選擇條件，可以通過建立兩個索引進行覆蓋,下面我們來看執行計畫:

　　非叢集索引的串連

　　非叢集索引的串連實際上是非叢集索引的交叉的一種特例。使得多個非叢集索引交叉後可以覆蓋所要查詢的資料，從而使得從減少查詢基本表變成了完全不用查詢基本表:

　　比如還是上面那兩個索引，這時我只查詢非叢集索引中包含的資料，則完全不再需要查詢基本表:

　　看起來這樣的查詢意義不大?但當你把查詢條件變為<號時呢?或者給定範圍時。還是有一定實際意義的。

　　非叢集索引的過濾

　　很多時候，我們並不需要將基本表中索引列的所有資料全部索引，比如說含有NULL的值不希望被索引，或者根據具體的業務情境，有一些資料我們不想索引。這樣可以:

　　減少索引的大小

　　索引減少了，從而使得對索引的查詢得到了加速

　　小索引對於增刪改的維護效能會更高

　　比如說,如下語句:

　　我們為其建立叢集索引後:

　　這時我們為其加上過濾條件，形成過濾索引:

　　由上面我們可以看出，使用過濾索引的情境要和具體的業務情境相關，對於為大量相同的查詢條件建立過濾索引使得效能進一步提升!

　　總結

　　本文從介紹了SQL SERVER中非叢集索引的覆蓋，串連，交叉和過濾。對於我們每一點從SQL SERVER榨取的效能的提升往往會伴隨著另一方面的犧牲。作為資料庫的開發人員或者管理員來說，以全面的知識來做好權衡將會是非常重要.系統的學習資料庫的知識不但能大量減少邏輯讀的資料，也能減少客戶打電話"關照”的次數:-)

原文傳送門