GUID主鍵，單獨的聚簇索引列

我在生產中有一個數據庫應用程序，並且所有表使用當前設置爲聚簇索引的GUID主鍵。由於性能考慮，我明白這是一個糟糕的設計。我一直在閱讀這個話題，其中包括Kimberly Tripp的this great article。GUID主鍵，單獨的聚簇索引列

我可以通過簡單地創建INT類型的自動遞增索引列並將其設置爲聚集索引來改善性能嗎？我從Kimberly的文章中瞭解到，所有非聚集索引（如我的GUID主鍵繼續前進，如果我這樣做）將引用聚集索引。但是如果我使用WHERE子句中的GUID主鍵搜索記錄，這實際上是否會提高性能？

另外，爲了獲得性能增益，我是否必須按創建記錄的自然順序填充現有記錄的新列？

編輯：爲了解決這個問題，即是否是this other question重複：另一個問題是問一般對於性能考慮使用GUID主鍵的最佳實踐。沒有討論具體的方法。另一方面，我的問題是要求特別是是否增加類型INT類型的自動遞增索引列將有助於改善帶有GUID主鍵的問題。此外，我的問題是問我是否必須按照「自然順序」填充新欄目才能實現收益，而由於其較高的通用性，另一個問題也未涉及。

來源

2015-01-14 rory.ap

是的，通過使用更合適的羣集密鑰來顯着減少碎片，您的性能應該會更好。 GUID將是唯一的 - 所以你總是隻提取一條記錄，所以即使有一個額外的密鑰查找，隨着時間的推移，更好的碎片行爲應該是有益的 –

可能的重複[有什麼使用GUID的最佳實踐作爲主要關鍵，特別是關於性能？]（http：// stackoverflow。com/questions/11938044 /使用guid-as-a-key-specific-rega的最佳做法） – AHiggins

@ Ahiggins - 請參閱我的編輯。 –

有一些事情要考慮：

是你正確的，聚集索引鍵會出現在所有的非聚集索引。使用較小的密鑰將有助於節省磁盤和緩衝池中的空間。
擁有一個身份的集羣鍵會讓你結束表插入，並可能（取決於負載）使該插入熱點。現在，GUIDS是隨機插入的，不會給出太多的熱點，但會導致更多的頁面拆分，這也可能會對性能產生不利影響。
要回答提高性能的問題，您目前的問題是什麼？有任何我們可以離開的數據嗎？如果您現在沒有任何問題，則可能不值得更改。
當您將該列添加爲標識時，它應該將其自身排序並且順序確實無關緊要。
如果確實使用INT列作爲鍵，請在GUID列上創建一個唯一的非聚集索引，以使優化器知道只有一個值（優化）並允許快速查找。如果它不太貴，請覆蓋它。

來源

2015-01-14 17:52:05

我會爭辯說，「插入熱點」是性能殺手比頻繁頁面拆分**少得多！根據我所瞭解的情況，熱點曾經是6.5/7.0版本中的一個問題 - 不再是真的了。但頁分裂是非常昂貴和雜亂的事務 - 要儘可能避免！ –

我發現通過刪除GUID索引上的填充因子可以緩解頁面拆分問題，特別是在大型表格上。刪除填充因子將在頁面中保留更多空間，但是您的索引開始變大。在這些情況下，我建議你可以創建一個複合自然鍵作爲聚集索引。這會將表格排序爲自然順序。 – Namphibian

@marc_s插入熱點導致閂鎖爭用，肯定會降低性能。頁面分割更糟糕，當然，但需要思考。 SQLCAT有一個分區散列表來分散熱點，但有它自己的問題。 –

GUID主鍵，單獨的聚簇索引列

回答

相關問題