叢集索引，非叢集索引，唯一索引，索引檢視表

文章目錄

• 叢集索引
• 非叢集索引
• 索引檢視表

叢集索引

叢集索引對於從表中檢索一定範圍的資料值非常有用。非叢集索引最適於檢索特定行，而叢集索引最適於檢索一定範圍的行。但是，由於每個表只允許使用一個叢集索引，因此按照這個簡單的邏輯來確定要建立哪種類型的索引並不總能成功。對於該問題有一個簡單的物理原因。對於叢集索引 B 樹結構的上部（非葉層），如果像對它們的非叢集索引部分那樣組織，則叢集索引的底層由表的實際 8 KB 資料頁組成。但這種情況有一個例外，那就是在視圖的基礎上建立叢集索引時。因為將在下面介紹索引檢視表，所以我們將討論針對實際表建立的叢集索引。在針對錶建立叢集索引時，會按與索引搜尋鍵相同的順序讀取與該表關聯的資料、對這些資料進行排序，並會在物理上將它們存回資料庫。因為該表的資料只能按照一種順序儲存到儲存空間中，不會導致重複，所以符合一個聚集的限制。

叢集索引和效能

叢集索引有一些會影響效能的固有特徵。

在使用叢集索引根據搜尋鍵來檢索 SQL Server 資料時，不需要指標跳轉（會導致硬碟上的位置可能不按順序更改）來檢索關聯的資料頁。這是由於叢集索引的葉層實際上就是關聯的資料頁。

如前所述，葉層（當然也包括表或索引檢視表的資料）在物理上會按照與搜尋鍵相同的順序進行排序和儲存。因為叢集索引的葉層包含表的實際 8 KB 資料頁，所以整個表的行資料會按照由叢集索引確定的順序以物理方式排列在磁碟機上。這就會在根據叢集索引的值從該表中提取大量行（至少大於 64 KB）時帶來潛在的 I/O 效能優勢，因為使用的是順序磁碟 I/O（除非該表上發生了頁面分割，這種情況將在題為“FILLFACTOR 和 PAD_INDEX”的一節中討論）。正因為如此，所以在檢索大量行時，一定要根據將用於執行範圍掃描的列來對錶選取叢集索引。

表中與叢集索引相關聯的行必須按照與索引搜尋鍵相同的順序排序和儲存，這一點具有以下意義：

• 在您建立叢集索引時，表會被複製，表中的資料會被排序，然後，原來的表會被刪除。所以，資料庫中必須有足夠的空閑空間來存放資料的副本。
• 在預設情況下，會在建立索引時對錶中的資料進行排序。但是，如果資料已按正確順序排過序，則會自動跳過排序操作。這樣就可以顯著加快索引建立過程。
• 將資料裝載到表中時的順序應儘可能與您計劃用於產生叢集索引的搜尋鍵的順序相同。對於大表（例如那些通常會成為資料倉儲特徵的表），該方法將大大加速索引建立過程，從而縮短您處理初始資料裝載所需的時間。只要表中的行仍保持未建立叢集索引時所排的順序，就可以在除去和重建叢集索引時可以使用該方法。任何行排序有誤，操作都會被取消，會出現相應的錯誤資訊，而且不會建立索引。
• 同樣，針對排過序的資料產生叢集索引時所需要的 I/O 也少得多，這是因為不必複製資料、對資料進行排序、將資料存回資料庫，然後刪除舊錶資料，而是會將資料留在原來分配給它的擴充盤區中。索引擴充盤區只是添加到資料庫中來儲存頂層節點和中間節點。

注意 針對大表產生索引的首選方法是：先產生叢集索引，然後產生非叢集索引。這樣，就不會因為資料移動而需要重建非叢集索引。在除去所有索引時，首先會除去非叢集索引，最後除去叢集索引。這樣，就不需要重建索引。

非叢集索引

非叢集索引最適於根據特定的索引值，從大型 SQL Server 表中提取少數幾個具有良好選擇性的行。如前所述，非叢集索引是由 8 KB 索引頁形成的二進位樹。索引頁二進位樹的底層或葉層包含組成該索引的列中的所有資料。在使用非叢集索引根據索引值的匹配項從表中檢索資訊時，會遍曆索引的 B 樹，直到在索引的葉層找到鍵的匹配項。如果需要表中不構成索引的列，指標就會跳轉。這種指標跳轉將有可能需要針對磁碟執行非順序 I/O 操作。它甚至可能需要從另一磁碟中讀取資料，尤其是在表及其伴隨的索引 B 樹很大時。如果多個指標指向同一個 8 KB 資料頁，對 I/O 效能的影響就會比較小，因為只需將該頁讀入資料緩衝一次。如果 SQL 查詢涉及到用非叢集索引進行搜尋，則對於對該查詢返回的每一行，至少需要一次指標跳轉。

注意 由於指標每次跳轉都會帶來與之相關的開銷，因此非叢集索引更適於處理從表中只返回一行或幾行的查詢。叢集索引更適於處理需要一系列行的查詢。

叢集索引和非叢集索引均可用於強製表內的唯一性，方法是在現有表上建立索引時指定 UNIQUE 關鍵字。確保表內唯一性的另一種方法是使用 UNIQUE 約束。如同唯一索引，UNIQUE 約束強制一組列中各值的唯一性。實際上，UNIQUE 約束的賦值自動建立基礎唯一索引，以利於強制該約束。由於唯一性可以作為 CREATE TABLE 語句的一部分來加以定義和記錄，因此，UNIQUE 約束通常優先於單獨唯一索引的建立。

 

索引檢視表

索引檢視表是為了實現快速存取而將其結果持續存放於資料庫內並建立索引的視圖。與任何其他視圖一樣，索引檢視表也依靠基表來提供視圖資料。此類相關性意味著，如果更改為索引檢視表提供資料的基表，索引檢視表可能變得無效。例如，重新命名為視圖提供資料的列會使該視圖無效。為了避免此類問題，SQL Server 支援建立具有架構綁定的視圖。架構綁定禁止對錶或列進行任何會使視圖無效的修改。使用視圖設計器建立的索引檢視表自動獲得架構綁定，因為 SQL Server 要求該索引檢視表具有架構綁定。架構綁定並不是說您不能修改視圖；它的意思是您不能按更改視圖結果集的方式來修改基礎資料表或視圖。另外，就像計算資料行上的索引一樣，索引檢視表也必須有確定性、精確，且不得包含 text、ntext 或 image 等列。

索引檢視表在基礎資料不經常更新的情況下效果最佳。維護索引檢視表的成本可能高於維護表索引的成本。如果基礎資料更新頻繁，索引檢視表資料的維護成本就可能超過使用索引檢視表帶來的效能收益。