聚集索引維護與非聚集索引維護
有大量可用資訊詳細說明為什麼在大多數
IDENTITY情況下應將欄位用作表的主鍵和聚集索引；但是我很難確定我的特殊情況是否是例外。我有一個大約有 250 列的表——我不想引發規範化辯論——大約有 100M 行。該表是頁壓縮的。在高峰日，大約 100 萬行按順序輸入到表中，其他連接的爭用為 0。
char(2) NOT NULL欄位和欄位的組合int NOT NULL保證是唯一的並且永遠不會改變。該欄位只有大約 10 個唯一值char(2)。
IDENTITY我關於將列用作聚集索引的論點完全基於性能。由於插入將按順序發生，因此我不必擔心閂鎖爭用；因此插入應該更快，因為不需要搜尋索引。另一方面，6 字節的組合密鑰相當小；無論如何我都會把它作為主鍵（char(2)首先是欄位）。此外，還會有一些其他表基於此表中的新行（可能通過過濾索引）*批量載入。*如果我使用一個IDENTITY列，我可能會將該列用作這些其他表的聚集索引和主鍵（沒有IDENTITY屬性），而不是使用“自然”複合鍵。在復合鍵上創建非聚集索引是否會使使用
IDENTITY列作為聚集索引的預期速度提升無效，因為在插入完成時必須搜尋該索引？編輯
根據評論，我更改了標題並提出了一個修改後的問題，其答案可用於回答上述原始問題。在插入方面，唯一聚集索引的維護與唯一非聚集索引的維護相比如何？非順序聚集索引是否與非順序非聚集索引類似？
令人尷尬的是，我從來不知道列儲存索引。該表主要用於分析；因此，根據 David Browne - Microsoft 在評論中的建議，我使用了一個聚集列儲存索引，並在
char(2)and欄位上定義了一個主鍵。int由於問題是關於與非聚集索引維護相比的聚集索引維護，因此我將盡我所能“回答”這部分。根據我的閱讀，當聚集索引具有頁面拆分時，它比在較小的非聚集索引（具有相同的鍵）上進行頁面拆分需要更多的資源。這是因為頁面在聚集索引中包含更多的數據。因此，如果我沒有使用列儲存聚集索引，我會使用（並測試）
IDENTITY聚集索引的列。話雖如此，評論中提供的影片 sp_BlitzErik非常資訊豐富——對於像我這樣的普通人來說很容易理解——並強調瞭如何基於 SQL Server 的舊實現“存在”許多過時的建議；因此，對外部分裂的擔憂可能被誇大了。