T-SQL查詢高級--理解SQL SERVER中非彙集索引的覆蓋，鏈接，交叉和過濾

 寫在前面:這是第一篇T-SQL查詢高級系列文章.可是T-SQL查詢進階系列還遠遠沒有寫完。這個主題放到高級我想是由於這個主題須要一些進階的知識做爲基礎..若是文章中有錯誤的地方請不吝指正.本篇文章的內容須要索引的知識做爲基礎。

 

簡介

---

    在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榨取的性能的提高每每會伴隨着另外一方面的犧牲。做爲數據庫的開發人員或者管理人員來講，以全面的知識來作好權衡將會是很是重要.系統的學習數據庫的知識不但能大量減小邏輯讀的數據，也能減小客戶打電話"關照」的次數:-)