GUID 與 INT 聚集索引列是否存在性能差異，尤其是在這些列上進行連接時？

基本上就是標題所說的：在 GUID 列上使用聚集索引與在 INT 列上使用聚集索引之間在性能（如果有的話）上有什麼區別，尤其是當這些列是連接謂詞的一部分時？

編輯：澄清一下，我一直假設 GUID 在連接謂詞中使用時的性能通常比 INT 差。我知道 GUID 是 INT 數據大小的 4 倍，但我問我的問題是要真正理解為什麼以及在“幕後”發生了什麼，導致 GUID 性能更差，即使在重建索引並且碎片差異最小之後也是如此兩種類型之間。

我知道 GUID 是 INT 數據大小的 4 倍，但我問我的問題是要真正理解為什麼以及在“幕後”發生了什麼，導致 GUID 性能更差，即使在重建索引並且碎片差異最小之後也是如此兩種類型之間。

我想說這個問題主要是你從這裡開始的，在我引用的內容中：UNIQUEIDENTIFIER比INT（16 字節與 4 字節相比）大 4 倍。這會以三種方式損害性能（我忽略了碎片，因為問題明確說明了這一點）：

1. 每一點比較都是另一回事。為 CPU 做更多的事情需要更多的時間。在查看 100 行時，現代系統不會注意到該時間。但是超過 100 萬行？現在您正在談論（以字節計），比較 1600 萬個事物與僅比較 400 萬個事物。
2. 記憶體不是免費的：無論是在金錢方面，還是在分配和解除分配所花費的時間方面。為了連接行，必須將包含這些行的數據頁讀入記憶體（緩衝池）。沒有無限量的記憶體（特別是如果您使用的是標準版或快捷版）。您在一項操作中佔用的記憶體越多，留給其他並發操作的記憶體就越少。但即使記憶體是無限的，將這些值載入到記憶體中以便進行比較仍然需要時間。載入 1600 萬字節自然比載入 400 萬字節需要更長的時間。
3. 磁碟不是免費的：即使使用 SSD，物理 I/O 仍然是您支付的成本，這就是為什麼將事物記憶體在記憶體中的原因。數據頁只有 8kb。如果您有一個 16 字節的值，與 4 字節的值相比，它將減少可以容納在該 8kb 數據頁上的行數。一個表佔用的數據頁越多，讀取和寫入相同數量的行所需的物理 I/O 就越多。

一個相關的問題是索引。您可能會為要加入的列編制索引。與主表相同的問題：每頁更少的索引行意味著索引需要更多的頁面，這意味著讀取和寫入受任何給定操作影響的每個索引花費更多的時間（表中的新行將需要在該表上的所有索引（減去將排除它的過濾索引），並假設我們正在談論聚集索引，聚集索引鍵被複製到所有非聚集索引）

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