當Guid是聚集索引時，通過Guid搜索表更快嗎？

Question

如果我要通過Guids查詢表格（不管Guid的碎片問題如何），將Guid作爲聚簇索引而不是非聚簇索引或根本沒有索引會更快嗎？

這個問題來自一個只讀的觀點。我只是很好奇，如果搜索行之間的速度會有所改善，並且搜索速度會更快，有/無索引，還是有/無聚簇索引？

另外，我相當肯定在答覆我的下一個問題，但現在將int標識符應用於上一個問題。搜索表是否由該int羣集會更快嗎？ （這是不是在表中聚集一些其他項目？）

我知道有張貼有關這個主題的其他許多問題，但我還沒有找到我要找的具體的答案在任何這些：
Should a Sequential Guid primary key column be a clustered index?
Improving performance of cluster index GUID primary key
Clustered primary key on unique identifier ID column in SQL Server
uniqueidentifier with index
Should I get rid of clustered indexes on Guid columns

感謝您的幫助！

Answer 1

假設MS SQL Server。這可能適用於或不適用於其他RDBMS：

如果您有一個聚集索引，那麼它將是最快的，但如果您搜索單個行，那麼它與非聚集索引之間的差異將可以忽略不計。當您使用非聚集索引時，服務器需要首先在索引中找到正確的值，然後從表存儲中獲取完整記錄。表存儲是聚集索引，因此通過聚集索引進行搜索可消除該步驟（稱爲書籤查找），但該步驟對於單個行幾乎不可察覺。

集羣索引傾向於在按範圍選擇的列（例如，交易日期和您想查找過去一個月的所有交易）時爲閱讀提供更大的優勢。在這種情況下，服務器可以找到開始，並在一次快速連續掃描中讀取數據。

INT上的非聚集索引（所有其他條件相同）將比使用GUID稍快，因爲索引本身會更小（因爲INT比GUID小得多），這意味着服務器具有遍歷更少的頁面以找到它想要獲得的價值。在聚集索引的情況下，我認爲如果你的行大小相比GUID和INT之間的差異已經很大，你就不會看到很大的差別，但是我還沒有做過任何測試。

Answer 2

對於整數聚簇索引，表格肯定會比GUID索引更快地查詢。原因是數據類型的大小。

如果您已經決定使用GUID作爲鍵，那麼可能使用newSequentialId（）而不是NewId（）來生成這些GUID，因爲這會減少Guid索引中碎片的影響，因爲Ids ae總是增加，有可能分頁。

加上我的觀點，除非你有一個聚集索引的潛在候選人，如果你使用這個GUID而不是關鍵目的，那麼這是一個自然的選擇。如果它是一個相對較小的表，那麼當你有一個沒有索引的選擇時，它總是有好的索引。

Answer 3

就像湯姆已經提到的那樣，在單個元素的聚集索引上搜索總是會更快。這是因爲聚集索引本身就是數據，並且在找到索引條目後不需要查找。

聚集索引的主要優點是能夠提取數據的「範圍」（如「上週」或「Orderhistory by Date」）。由於GUID傾向於平均分佈在桌面上，因此您無法在此獲得此優勢。另外每個表只能有一個聚集索引，所以要仔細挑選。

如果您查詢某個表最常用的特定範圍，則將其視爲聚集索引。

還有第三類，它被稱爲覆蓋指數。覆蓋索引由幾個字段組成，這將能夠滿足最常見的查詢。例如，您有一個帶有ID，Displayname，Password，LogonDate，.....的USER表，並且您將經常需要DisplayName，根據ID創建索引，Displayname將被視爲查詢的覆蓋索引，如

Select Displayname from USER where ID=XYZ

編輯： 有一件事我忘了提。當涉及到SQL時，GUID是一個相當大的對象（呃... 16字節）。將其作爲聚簇索引強制該表上的所有其他索引將16字節指針包含到GUID中。如果你在該表上有一堆索引，這可以加起來。集羣指數最好的是它小而獨特。這就是爲什麼INTs非常好。