聚集索引
聚集索引對于從表中檢索一定范圍的數據值非常有用。非聚集索引最適于檢索特定行，而聚集索引最適于檢索一定范圍的行。但是，由于每個表只允許使用一個聚集索引，因此按照這個簡單的邏輯來確定要創建哪種類型的索引并不總能成功。對于該問題有一個簡單的物理原因。對于聚集索引 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 等列。
索引視圖在基礎數據不經常更新的情況下效果最佳。維護索引視圖的成本可能高于維護表索引的成本。如果基礎數據更新頻繁，索引視圖數據的維護成本就可能超過使用索引視圖帶來的性能收益。