Sql-Server
GUID(uniqueidentifier) 不適合聚集索引嗎？
當我對主鍵列使用 uniqueidentifier 數據類型時，它會自動創建聚集索引……那麼，它會減慢我的查詢速度嗎？
我正在解釋我的問題的一些描述。我有兩個發布者將數據複製到一個訂閱者（即主 Alwayson）中，那麼在這種情況下如何維護主鍵值？
那麼，請給我一個保持主鍵值的想法？
它會減慢插入而不是查詢。那是因為它本質上是在現有記錄中的某個地方隨機插入一條記錄，而不是僅僅在最後敲擊它（就像您使用身份或連續日期一樣）。
您可以通過使用 NEWSEQUENTIALID 而不是 NEWID 在一定程度上減少這種情況（假設 GUID 是由數據庫而不是您的應用程序生成的）。
如果有任何可能避免將 GUID 作為主鍵/唯一聚集索引，請選擇此選項！
一個好的（代理）鍵應該是：
- N箭頭（否）
- 唯一（ GUID是）
- 靜態（GUID 是）
- 不斷增加（否）
GUID（唯一標識符）需要 16 個字節 - int（最多 2^31 - 1 的數字）需要 4 個字節，bigint（最多 2^63 -1 的數字，遠遠超過您的需要）需要 8 個字節！
如果沒有自然鍵候選，我總是使用帶有身份規範的 int/bigint 代理鍵。我從來沒有遇到過必須使用 GUID 的情況。