上個星期我討論了SQL Server里的聚集索引。當你在表上定義了一個聚集索引，你是物理上把你的表數據按提供的聚集鍵列的順序存儲。在SQL Server里，一個表只能定義一個聚集索引，非聚集索引可以定義多個（最多999個）。

非聚集索引是第二索引，你可以在表上列進行定義。你也可以把非聚集索引與書比較。但是這次你把它認為類似T-SQL 語言參考的書。書本身就是一個聚集索引，不同的T-SQL命令是按它們的名字物理排序的。在書的最后，你會看到一個索引。當你查找一個T-SQL 命令（例如 CREATE TABLE)，你可以使用書最后的索引，來找到這個命令詳細介紹的位置。

這里書會給你一個查找值——頁碼，在那里你可以找到這個命令的詳細信息。這與SQL Server里（非聚集索引）的概念是一樣的：但給你在執行計劃里通過非聚集索引訪問你的表，SQL Server會在非聚集索引的葉子層給你查找值，你可以用它找到這條記錄的更多信息。SQL Server需要用這個查找值做導航，從非聚集索引到聚集索引或堆表里找到記錄其他列值，這些列不是非聚集索引的一部分。在SQL Server里這個被稱為書簽查找（Bookmark Lookup）。我們來看看它的更多細節。

每次不在查詢的執行計劃里訪問非聚集索引，你查詢里的一些列不是非聚集索引的一部分，SQL Server需要在執行計劃里進行書簽查找操作。下圖是一個執行計劃里典型的書簽查找：

可以看到，SQL Server在Person.Address表里進行非聚集查找操作。另外SQL Server通過鍵查找（Key Lookup）（聚集的）操作從聚集表獲取所有其他列。這個看起來是SQL Server里很酷的功能，但是實際上，書簽查找是非常，非常，非常危險的！

它們會導致書簽查找死鎖，性能會受老的過期的統計信息影響，當你與參數嗅探問題（Parameter Sniffing）打交道時也是。書簽查找只會在與非聚集索引組合時發生。因此，下星期我們會討論下在執行計劃里如何避免書簽查找，還有為什么有時候SQL Server會完全忽略你的近乎完美的非聚集索引。

像我剛才說過的，SQL Server在非聚集索引的葉子層保存查找值，用來指向存在聚集表或堆表的記錄。當你在堆表定義了一個非聚集索引，這個查找值稱為行標識者（Row-Identifier）查找值。它是8 bytes長的值，包含記錄物理存儲的頁號（4 bytes），文件號（2 bytes），還有槽號（2 bytes）。

如果你在聚集表上定義你的非聚集索引，SQL Server使用聚集鍵值作為查找值。這意味你你要認真選擇的聚集鍵列都是每個非聚集索引的一部分。在聚集和非聚集索引之間有著巨大的依賴關系。聚集鍵基本上是你表里的冗余數據。因此，當你選擇聚集鍵列時，你真的需要認真考慮。因為它的強大依賴性，選擇的最佳聚集鍵應該有3個特性：

• 唯一的（Unique）
• 范圍小的（Narrow）
• 靜態的（Static）

用心記住它們，因為你的聚集鍵始終出現在每個非聚集索引里。

非聚集索引對提高你的查詢性能非常重要。不好非聚集索引的設計會讓你引入書簽查找，這會引入巨大的問題和副作用到你的數據庫里。如果你想對非聚集索引內部結構有更深入的理解，可以看看下列文章

• 索引深入淺出：非聚集索引的B樹結構在聚集表。
• 索引深入淺出：非聚集索引的B樹結構在堆表
• 自增長的聚集鍵值不會擴展（scale）

按照我們的約定，下星期我會講下使用覆蓋非聚集索引（Covering Non-Clustered Indexes）來避免書簽查找（Bookmark Lookups）。還有臨界點（Tipping Point），它用來定義SQL Server是否在使用非聚集索引。請繼續關注！