集群順序 GUID 主鍵與非集群 GUID 和集群順序 ID 主鍵

我試圖弄清楚當使用 GUID 作為主鍵時，在大小和性能方面的最佳解決方案是什麼。想要 GUID 的主要原因是它更適合我們的微服務架構。關於什麼是最好的似乎有很多爭論。

兩個主要的解決方案似乎是：

1. 將主鍵作為具有聚集索引的順序 GUID（由應用程序生成，而不是在 NEWSEQUENTIALID() 中建構的 SQL Server，因為它不是真正的順序）。
2. 有兩個主鍵，一個隨機生成的帶有非聚集索引的 GUID 和一個帶有聚集索引的基本 int IDENTITY 列——該方法在此處的堆棧溢出響應中得到了最好的描述

我不確定哪種解決方案最好。第一種方法似乎是我讀過的最流行和最廣泛使用的方法。第二個似乎從連結的stackoverflow響應中受益：

然後還有另一個問題需要考慮：表上的集群鍵也將被添加到表上每個非聚集索引的每個條目中——因此你真的想確保它盡可能小。

任何意見，將不勝感激。

如果您要使用 GUID 鍵，只需使用帶有 NEWSEQENTIALID() 的聚集索引，然後繼續您的應用程序。當您考慮它們引入的額外資料結構和復雜性時，替代設計根本無法預測並且明顯更好。因此，雖然對您的實際應用程序進行仔細測試可能會發現一個更好的替代設計，但只需從按順序生成的 GUID 上的簡單聚集索引開始。

有關為什麼在排序順序的“中間”生成 GUID 以及插入點更改並不重要的詳細資訊，請參閱：Good Page Splits and Sequential GUID Key Generation。

引用自：https://dba.stackexchange.com/questions/223737