每次你改變聚簇索引鍵的值時，都會發生兩件事。 首先，SQL Server將行移動到聚簇索引頁鏈和資料檔案中的不同位置。 其次，它更新聚集索引鍵，行編號。 行編號被儲存起來而且要在所有非聚簇索引中更新。 對於I / O而言，這花銷可能很昂貴，尤其是在批處理更新的情況下。此外，它可以增加聚簇索引的碎片，並且在行編號增加的情況下，可以增加非聚簇索引的碎片。 因此，最好在鍵值不變的情況下使用靜態聚簇索引。

所有非聚簇索引都使用聚簇索引鍵作為行編號。太寬的聚簇索引鍵會增加非聚簇索引行的大小，同時需要更多空間來儲存。因此，SQL Server在索引或範圍掃描操作期間需要處理更多的資料頁，這會降低索引的效率。

對於非惟一的非聚簇索引，行編號也儲存在非葉索引級別，這反過來減少了每頁索引記錄的數量，並可能導致索引中的額外中間級別。 儘管非葉索引級別通常快取在記憶體中，但每次SQL Server遍歷非聚簇索引B-Tree時，這都會引入額外的邏輯讀取。

最後，較大的非聚簇索引在緩衝池中佔用更多空間，在索引維護期間引入更大的開銷。顯然，它不可能提供一個通用閾值來定義可應用於任何表的金鑰的最大可接受大小。但是，通常情況下，最好使用一個小的聚簇索引鍵，索引鍵越小越好。

定義唯一的聚簇索引也是有好處的。 這個原因重要但不明顯。 考慮到一種情況，表沒有唯一的聚簇索引，你希望在執行計劃中執行使用非叢集索引查詢的查詢。 在這種情況下，如果非聚簇索引中的行編號得到的就不是唯一的，SQL Server就不知道在鍵查詢操作期間要選擇哪個聚簇索引行。

SQL Server通過向非唯一聚簇索引中新增另一個名為uniquifier的可空整數列的操作來解決此類問題。對於第一次出現的鍵值，SQL Server用NULL填充uniquifiers，並對插入到表中的後續重複值進行自動遞增操作。

注意：每個聚簇索引鍵值的可能重複項數量受整數域值的限制。使用相同的聚集索引鍵的行不能超過2,147,483,648。 這是理論上的限制，建立一個選擇性這麼差的索引顯然是個不好的方式。

讓我們看看在非唯一聚簇索引中引入uniquifiers的開銷。列表7-1所示的程式碼建立了三個相同結構的不同表，每個表都填充了65,536行。dbo表。表dbo.UniqueCI是唯一定義了唯一聚簇索引的表。表NonUniqueCINoDups沒有任何重複的鍵值。最後一個表dbo.NonUniqueCDups在索引中有大量重複項。

列表7 - 1 非唯一聚簇索引：表建立

圖7-1  非唯一聚簇索引：聚簇索引的行大小

  即使dbo.NonUniqueCINoDups表中沒有重複的鍵值，該行仍然會新增兩個額外的位元組。 SQL Server將一個uniquifier儲存在資料的可變長度部分中，這兩個位元組就被新增到可變長度資料偏移陣列中的另一個條目中。

這種情況下，當聚簇索引具有重複值時，uniquifiers將再新增4個位元組，這就造成總共6個位元組的開銷。

值得一提的是，在某些邊緣情況下，uniquifier使用的額外儲存空間可以減少可以放入資料頁面的行數。我們的例子說明了這種情況。如你所見，dbo.UniqueCI使用的資料頁數比其他兩個表少15％。

現在，讓我們看看uniquifier如何影響非聚簇索引。列表7-3所示的程式碼在所有三個表中建立了非聚簇索引。圖7-2顯示了這些索引的物理統計資訊。

列表7-3 非唯一聚集索引:檢查非聚集索引的行大小

圖7-2  非唯一聚簇索引：非聚簇索引的行大小

dbo.NonUniqueCINoDups表中的非聚集索引沒有開銷。 你應該還記得，SQL Server不會將偏移量資訊儲存在NULL資料的尾隨列的可變長度偏移陣列中。儘管如此，uniquifier在dbo.NonUniqueCIDups表中也引入了8個位元組的開銷。 這八個位元組由一個4位元組的unquifier值，一個雙位元組的可變長度資料偏移陣列條目和一個儲存行中可變長度列數的雙位元組條目組成。

我們可以通過以下方式總結uniquifier的儲存開銷。 對於具有uniquifier但為NULL的行，如果索引中至少有一個儲存NOT NULL值的可變長度列，那就會產生兩個位元組的開銷。 該開銷來自uniquifier列的可變長度偏移陣列條目。否則沒有開銷。

在填充uniquifier的情況下，如果存在儲存非空值的可變長度列，則開銷為6個位元組。否則，開銷是8個位元組。

提示：如果預計聚簇索引值中存在大量重複項，可以將整數標識列作為最右邊的列新增到索引中，從而實現唯一性。 與uniquifiers引入的最多8位元組的不可預測儲存開銷相比，這將為每行增加一個4位元組的可預測儲存開銷。當你通過其該行的聚簇索引列使用該行時，這還可以提高單個查詢操作的效能。

用最小化插入新行引起索引碎片化的方式設計聚簇索引是有好處的。實現這一點的方法之一是不斷增加聚簇索引值。 標識列上的索引就是一個這樣的例子。 另一個示例是使用插入時的當前系統時間填充的datetime列。

然而，索引不斷增加會存在兩個潛在問題。第一個與統計有關。就像你在第3章中瞭解到的，當直方圖中沒有引數值時，SQL Server中的遺留基數估計器會低估基數。你應該將這種行為考慮到系統的統計維護策略中，除非你使用新的SQL Server 2014-2016基數估計值，該估計值假定在直方圖之外的資料具有類似於表中其他資料的分佈。

下一個問題更復雜。 隨著索引的不斷增加，資料總是插入到索引的末尾。 一方面，它可以防止頁面拆分並減少碎片。 另一方面，它可能導致熱點，即當多個會話試圖修改相同的資料頁和/或分配新的頁或區段時發生的序列化延遲。SQL Server不允許多個會話更新相同的資料結構，而是通過序列化執行這些操作。

除非系統以非常高的速率收集資料並且索引每秒處理數百個插入，否則熱點通常不是問題。 我們將在第27章“系統故障排除”中討論如何檢測此類問題。

最後，如果系統有一組頻繁執行且重要的查詢，就要考慮到聚簇索引這時候是有好處的，它會優化它們。這解決了昂貴的金鑰查詢操作花銷並提高了系統的效能。

即使可以使用覆蓋非聚簇索引來優化此類查詢，但它並不總是理想的解決方案。 在某些情況下，它需要你建立非常大的非聚簇索引，這將佔用磁碟和緩衝池中的大量儲存空間。

另一個重要因素是修改列的頻率。將經常修改的列新增到非聚簇索引上需要SQL Server在多個位置更改資料，這會對系統的更新效能產生負面影響，並增加阻塞。

儘管如此，並不總能設計滿足所有這些準則的聚簇索引。 此外，你不應將這些指南視為絕對要求。應該分析系統，業務需求，工作負載和查詢，並選擇適當的聚簇索引，即使它們違反了某些準則。

身份，序列和唯一識別符號

人們通常選擇身份，序列和唯一識別符號作為聚簇索引鍵。 與前面的一樣，這種方法有其自身的優缺點。

在此類上定義的聚簇索引是唯一的，靜態的和窄的。此外，身份和序列不斷增加的同時也減少了索引碎片。一個理想的用例是目錄實體表。作為示例，你可能會考慮到儲存客戶，文章或裝置列表的表。 這些表儲存數千甚至數百萬行，但是資料相對靜態，因此熱點不是問題。 此外，這些表通常由外來鍵引用並用於連線。 integer或bigint列上的索引非常緊湊和高效，這將提高查詢的效能。

注意：我們將在第8章“約束”中更詳細地討論外來鍵約束。

在事務性表中，身份或序列列上的聚集索引效率較低，事務性表以非常高的速率收集大量資料，這是由於它們引入的潛在熱點造成的。

另一方面，對於聚集索引和非聚集索引，uniqueidentifier很少是一個好的選擇。使用NEWID()函式生成的隨機值極大地增加了索引碎片。此外，uniqueidentifiers上的索引會降低批處理操作的效能。我們看一個示例並建立兩個表:一個表在標識列上具有聚簇索引，另一個表在uniqueidentifier列上具有聚簇索引。下一步，我們將在兩個表中插入65,536行。你可以在列表7-4中看到執行此操作的程式碼。

列表7-4 Uniqueidentifiers：表建立

我的計算機上的執行時間和讀取次數如表7-1所示。 圖7-3顯示了兩個查詢的執行計劃。

  表7-1。 將資料插入表：執行統計

圖7-3  將資料插入表中：執行計劃           

就像你看到的，uniqueidentifier列上的索引有另一個排序運算子。SQL Server在插入之前對隨機生成的uniqueidentifier值進行排序，這種操作會降低查詢的效能。接下來我們在表中插入另一批行並檢查索引碎片。執行此操作的程式碼如列表7-5所示。圖7-4顯示了查詢的結果。    

列表7-5 Uniqueidentifiers：插入行並檢查碎片

圖7-4。 索引碎片

正如你所看到的，uniqueidentifier列上的索引嚴重碎片化，與標識列上的索引相比，它使用的資料頁大約多40％。

在uniqueidentifier列的索引中的批量插入會變成在資料檔案的不同位置插入資料，當表太大這會出現繁重的隨機物理I / O. 這可能會降低操作效能。

前段時間，我參與了一個系統的優化，該系統具有250 GB的表，其中包含一個聚簇索引和三個非聚簇索引。 其中一個非聚簇索引是uniqueidentifier列上的索引。通過刪除此索引，我們能夠將50,000行的批量插入從45秒加速到7秒。

當你想要在uniqueidentifier列上建立索引時，有兩種常見方法。 第一個是支援跨多個數據庫的值保證唯一性。其中行可以插入到分散式系統的每個資料庫中。開發人員經常使用uniqueidentifiers來確保每個鍵值在系統範圍內都是唯一的。

像這種實現的關鍵元素是如何生成鍵值。就像你已經看到的，NEWID()函式或客戶機程式碼中生成的隨機值會對系統性能產生負面影響。但是，你可以使用NEWSEQUENTIALID()函式，該函式會生成遞增的唯一的值(SQL Server不時重置它們的基值)。使用NEWSEQUENTIALID()函式生成的uniqueidentifier列上的索引類似於標識列和序列列上的索引;但是，你要記住，uniqueidentifier資料型別使用16位元組的儲存空間，而4位元組的int或8位元組的bigint資料型別。 

作為替代解決方案，你也可以建立兩列的複合索引（InstallationId，Unique_Id_Within_Installation）。 兩列的組合保證了多個安裝和資料庫的唯一性，並且比獨特識別符號使用更少的儲存空間。 你可以使用整數標識或序列來生成Unique_Id_Within_Installation值，這將減少索引的碎片。 

在需要跨資料庫後所有實體生成唯一鍵值的情況下，可以考慮跨所有實體使用單個sequence物件。這種方法可以滿足需求，但是使用到比唯一識別符號更小的資料型別。

另一個常見方法是安全性，其中uniqueidentifier值用作安全性令牌或隨機物件編號。 不幸的是，你無法在此方案中使用NEWSEQUENTIALID（）函式，因為可以猜測該函式返回的下一個值。

在這種情況下，一種可能的改進是不在uniqueidentifier列上建立索引，而是使用CHECKSUM（）函式建立計算列，然後對其進行索引。 程式碼如列表7-6所示。

  列表7-6 使用CHECKSUM（）：表結構