25k插入每日99％碎片集羣GUID索引

Question

我有一個表具有主鍵作爲集羣GUID字段;我使用NEWSEQUENTIALID()而不是NEWID生成GUID。不幸的是，因爲這個表每天看到〜25k-100k的插入，在幾個小時內（默認：集羣）主鍵索引變成99％碎片。

我最初使用NEWID而不是生成順序ID，但即使重新創建表並重新插入使用NEWSEQUENTIALID（並指定作爲主鍵列的默認值）的所有行，我仍然看到順序中的碎片在幾個小時內達到99％。 （該表目前有大約130萬條記錄

我曾想過用一個整數主鍵替換GUID，但我不確定這是否會起作用;另外，因爲我們的團隊使用主鍵的GUID而不是整數前進，我不認爲我會有足夠的買進來做到這一點。

什麼是我的選項，以保持這個東西整理？我使用SQL Server Express，所以我沒有有權訪問SQL代理（因此不能定期運行維護計劃來重建索引）

我也可能很可能在將來的某個時間點拆分此數據庫/表（由於數據量），所以我可能需要合併表的GUID。

另外：我不能使用索引視圖，因爲我有一個內部選擇，這將很難放鬆到一個連接。

Answer 1

以我個人的經驗，拋出GUID s作爲您的羣集密鑰可以h對你的系統有很大的正面影響 - 特別是在索引碎片方面！

我的新INT IDENTITY聚類指數幾乎沒有任何碎片 - 即使經過數月激烈的日常生產使用。絕對值得！

使用Guid數據類型作爲SQL Server中的集羣密鑰是可怕的糟糕選擇 - 無論您以何種方式查看它...

看到一些金佰利特里普的（女王索引）的博客文章的題目是

• GUIDs as primary keys and/or clustering keys
• Disk space is cheap - THAT's NOT THE POINT!

和別的她在博客上聚集鍵的話題...

Answer 2

看一看this simple query in the stackexchange data explorer。它看起來像newsequentialid()遞增最重要的部分guid，而不是最小。這將成爲你所看到的碎片化的一個可能原因。

如果您必須使用guid，可能需要考慮通過代碼生成它們，並在插入語句中發送它們，而不是依賴於生成它們的數據庫。使用「comb」技術，將當前時間戳用作guid的一部分，在最不重要的數字中遞增。

---

編輯

..或者，如果你不想生成它們的代碼，你可以在數據庫

CAST(CAST(NEWSEQUENTIALID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER) 

爲默認值的範圍內做這樣的事情，根據this modification to the above query

Answer 3

這是Guid索引的預期行爲ge插入的數字。大多數情況下，您選擇guid作爲密鑰只有，因爲記錄是由多個來源生成的，並且您需要使各個來源不會踩在彼此的腳趾上。這裏的一個例子是離線的移動設備。當沒有連接時，該領域的工作人員需要創建新記錄，因此移動設備可以安全地使用guid作爲密鑰創建記錄。當稍後重新聯機時，設備可以安全地與數據庫同步，而不用擔心任何關鍵衝突。

如果您在單臺服務器上生成GUID，通常最好使用簡單的標識列。如果你真的想要guid，你仍然可以包含它們......你可能想要考慮一下使用它們作爲你的聚集索引。您可能想要在guid上進行聚簇的唯一原因是，如果稍後您將回到表中並根據它的指導一次查詢一條記錄。你看到的插入率似乎不太可能。但是，如果是這種情況，可以通過減少索引上的填充因子來幫助緩解事情。這將增加使用的磁盤空間量（並且意味着稍後會有更多的磁盤查找），但頁面填滿的速度會更快，並且您將避免某些索引重新洗牌。