我們有一個數據庫，其中所有的PK都是GUID，大多數PK也是表的聚集索引。我們知道這是不好的（由於GUID的隨機性）。所以，看起來這裏基本上有兩種選擇（儘量不要把GUID全部扔出去，這是我們不能做的（至少現在不行））。具有羣集GUID PK的SQL Server數據庫 - 切換聚簇索引或切換到順序（梳）GUID？
在這種情況下是否可以給出任何一般性建議？
有問題的應用程序有500多個表格，最大的一個目前大約有一百五十萬行，幾個表格大約有五十萬行，其餘大大低於大多數（大部分遠低於10K）。
此外，該應用程序已安裝在多個客戶站點，因此我們必須考慮現有客戶的任何可能的負面影響。
謝謝！
如果：
爲什麼GUID的是壞在SQL Server這裏聚集鍵退房金佰利特里普的優秀系列你可以改變你的那麼這很可能是你的快速勝出選項。順序guid將停止表中的碎片，同時保留爲聚簇索引。然而，連續引導的主要缺點是，它們隨後變得可以猜測，而這往往是不希望的，並且首先使用guid的原因。
如果你沿着你的羣集主鍵的Identity路徑，然後只是你的GUID列上的索引，那麼你仍然會在你的GUID索引中得到很多碎片。然而，桌子不再分散的事實將是一個巨大的收益。
最後，雖然我知道你說你現在不能這樣做，但是，如果你不需要使用GUID作爲索引，那麼你可以刪除所有這些問題。
我的意見很明確：爲集羣密鑰使用INT IDENTITY。這是迄今爲止最好的，最優化的聚集鍵，因爲它：
順序GUID的絕對是一個比普通的隨機GUID好很多，但仍然比INT（16比4個字節）大4倍，如果你的表中有很多行，並且這張表上有很多非聚集索引，這也是一個因素。羣集密鑰正被添加到每個非聚簇索引中，因此會顯着增加16個字節和4個字節大小的負面影響。更多的字節意味着磁盤和SQL Server RAM中的頁面更多，因此更多的磁盤I/O和更多的SQL Server工作。
在適當情況下，您肯定可以將GUID保留爲主鍵 - 但在這種情況下，我強烈建議在該表中添加一個單獨的INT IDENTITY，並使該INT成爲集羣密鑰。我自己用很多大表來完成這個工作，結果令人驚訝 - 表碎片從99％降到了百分之幾，性能也好多了。
馬克
謝謝你的回答。簡單的評論/澄清：我不關心GUID的可猜測性，只關心它們在整個安裝過程中的獨特性。 – Eyvind 2010-04-09 09:17:07
然後，只需將您的guid更改爲像SQLSEQ中的NEWSEQUENTIALID（）這樣的連續GUID，就可以解決大部分即時問題。但是，不要將完全重新考慮因素放入身份中，而不能超過必要時間。 – 2010-04-09 09:26:17
因此，考慮到我們選擇了連續的GUID：對於在許多表格中有100K行的客戶呢？這樣的改變會使他們受益，還是情況會和今天一樣糟糕，因爲表格和索引已經是充滿「隨機」數據？ – Eyvind 2010-04-09 10:51:59