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

Question

我在生產中有一個數據庫應用程序，並且所有表都使用當前設置為聚簇索引的GUID主鍵。 據我所知，由於性能考慮，這是一個糟糕的設計。 我一直在閱讀這個主題，包括金伯利·特里普的這篇精彩文章 。

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

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

編輯：要解決此問題是否與此另一個問題重復：另一個問題是詢問有關使用GUID主鍵的性能注意事項的一般最佳實踐。 沒有討論具體方法。 另一方面，我的問題是具體詢問添加INT類型的自動遞增索引列是否有助於改善GUID主鍵的問題。 此外，我的問題隨后問我是否必須按照“自然順序”填充新專欄以實現其中的好處，由於其更高的通用性，這一問題在另一個問題中沒有得到解決。

Answer 1

有幾點需要考慮：

1. 是的，您是正確的，聚簇索引鍵將出現在所有非聚簇索引中。 使用較小的密鑰有助於節省磁盤空間和緩沖池空間。

2. 擁有標識的聚簇鍵將為您提供表插入的結尾，並且可能（取決於負載）使其成為插入熱點。 現在GUIDS是隨機插入的，並且不會給出如此多的熱點，但會導致更多的頁面拆分，這也可能對性能產生負面影響。

3. 要回答提高性能的問題，您目前的問題是什么？ 有任何我們可以解決的數據嗎？ 如果您現在沒有任何問題，可能不值得進行更改。

4. 當您將列添加為標識時，它應該自行播種，順序確實無關緊要。

5. 如果對鍵使用INT列，請在GUID列上創建唯一的非聚集索引，以使優化器知道只有一個值（優化）並允許快速搜索。 如果不太貴，請將其覆蓋。