利用索引來提升SQL Server視圖的運行效能(一)

　　眾所周知，索引可以提高資料庫表的效能。但是，索引也可以提高資料庫檢視的效能，恐怕知道的人不多。其實，視圖也被稱為虛擬表，視圖返回的結果集通常情況下與表結構相同，都是由列與行相同。不僅如此，其引用方式也相同。每次資料庫使用標準視圖時，都會在系統內部將視圖的定義轉化為查詢語句，到基表中去查詢資料。然後把結果集返回。

　　由於在使用者引用視圖的時候，每次都需要從資料庫中重新查詢資料，即使基表中的資料沒有變化也是如此。可是，每當使用者引用視圖時查詢動態產生結果集會產生比較大的系統開銷，特別是對於那些涉及大量進行複雜處理的視圖。如有時，使用者需要統計一年的銷售表表，需要對每月的銷售金額、每個業務員接單的金額、每個產品涉及到的金額等等進行統計，這個查詢就會消耗系統比較多的資源。如果每次查詢這個統計視圖的話，資料庫都從基表中查詢並產生相應的結果集，會大大影響視圖的效能。

　　為瞭解決這個問題，資料庫專家提出了索引檢視表的概念。即通過對視圖建立唯一叢集索引來提高資料庫效能。對視圖建立唯一索引後，結果集就會被儲存在資料庫表中，就好戲那個帶有叢集索引的表一樣。如此的話，不用每次引用視圖，資料庫都做一次查詢作業了。而可以直接從資料庫中取得這個結果集。那麼就可以提高視圖的執行效能了。

　　一、 在什麼時候使用索引檢視表?

　　當然，並不是說在任何情況下為視圖建立唯一叢集索引都可以提高視圖的效能。俗話說，過之而不及，如果採取這種極端方式的話，往往會取得相反的結果。通常情況下，若遇到如下幾種情況，則在索引檢視表中建立索引能夠帶來比較大的收益。

　　一是視圖需要處理大量行的串連與彙總。如在進銷存系統中，有一張銷售訂單出貨情況統計表。在這張報表中，需要涉及到大量的表與行。如需要涉及到訂單頭表(擷取訂單資訊)、訂單行表(擷取訂單內容以及預計交貨日期等資訊)、客戶資訊表、運費資訊表、出貨單頭表、出貨單身表、發票資訊表等表，。並且需要對錶中的資料行進行重新串連。並且，還要實現部分的統計功能，如需要統計每個月的出貨總額、開票總額等等;也可能需要根據客戶來統計等等。這些統計工作會產生大量的彙總操作。為此，如果執行這個查詢的話，當資料量一多，其啟動並執行時間就會比較長。如果採用不帶唯一叢集索引的視圖的話，則每次產生這個報表都會花費比較長的時間。但是，如果對於這張表採用索引檢視表的話，那麼其執行速度就會快的多。因為引用這張視圖的時候，不用在資料庫中重新查詢。

　　二是在一些資料更新不怎麼頻繁的資料庫應用中，如決策分析系統。決策分析系統有兩個很明顯的特點，一是在他的資料庫系統中儲存的資料不是經常需要更新、匯總的彙總資料。二是在查詢時需要對大量的行進行串連、彙總操作。而且這些行所涉及到的表往往是具有大量的列或者列很大的寬表。用這些列的窄子集的查詢可以從只包含查詢中的列或這些列的窄超集的索引檢視表中獲益。建立包含單個表的列的子集的窄索引檢視表稱為“垂直資料分割”策略，因為它垂直分割表。不過，這裡需要注意一點。如果要垂直分割整個表，而不是表的一個子集，建議您使用表的非叢集索引，該索引使用
INCLUDE 子句只包含所需的列，而不是索引檢視表。這兩個方面具體的差異，筆者會在日後的文章中談到。

　　所以說，並不是在任何情況下都推薦使用索引檢視表。如只是對於兩張基表的視圖，而且這些表中的資料量並不是很多，那麼採取索引檢視表反而會降低資料庫的整體效能。故是否要建立索引檢視表，其一般的判斷標準就是兩個，即是否需要對大量表中大量的行進行串連與彙總操作;另外一個就是資料庫表中資料的更新程度。

　　二、 使用索引檢視表有什麼限制?

　　在上面筆者談到了在什麼情況下適合採用索引檢視表。在接下去的內容中，筆者還將談談索引檢視表的限制條件。即在什麼情況下，若採用索引檢視表則可能是事倍功半。

　　一是如果視圖所對應的基表涉及到頻繁的更新操作時，則不宜採用索引檢視表。因為維護索引檢視表的成本可能高於維護表索引的成本。如果經常更新基礎資料，則維護索引檢視表資料的成本可能超過使用索引檢視表所帶來的效能收益。例如，在某些決策支援分析系統中，需要對基礎資料以批處理的形式定期更新，但是在更新之後主要作為唯讀資料進行處理。此時，資料庫管理員就需要在更新資料前先把所有相關的索引檢視表設定為無效或者刪除，然後再啟用或者重建。這樣做可以避免因資料更新而給資料庫帶來的額外負擔，提高更新的效能;同時也利於後續的查詢分析操作。