我有一個結表在我的SQL Server 2005中包含兩列的數據庫：Sql Server：uniqueidentifier加整數複合PK ...使用什麼類型的索引？
OBJECT_ID（唯一標識符）
PROPERTY_ID（整數）
這些值加在一起使一個複合主鍵。
爲SELECT性能創建此PK索引的最佳方式是什麼？
如果列是兩個整數，我只會使用複合聚集索引（默認值）。但是，當涉及uniqueidentifiers時，我聽說聚簇索引有壞處。
任何人都有這種情況的經驗？
是的，GUID對於聚簇索引是非常不利的，因爲GUID在設計上非常隨機，因此導致大規模的碎片化和性能問題。
請參閱Kim Tripp的博客 - 最值得注意的是「The CLustered Index Debate continues」和「GUIDs as PRIMARY and/or CLUSTERED key」 - 瞭解大量有價值的背景信息。
如果你真的需要在這兩列上有一個索引，我會建議一個非聚集索引 - 它可以是一個主索引 - 最好不是聚集索引。
馬克
我，我會創建一個標識列&然後使這個主鍵&聚集索引。然後，您可以根據需要在objectid propertyid上創建非聚簇索引。
您可以創建一個唯一約束來確保您的密鑰的唯一性。
原因是這些行將按順序插入，因此您的縮小頁面會分裂。另外對你的PK使用一個整數意味着你的聚集索引值較小。
ObjectID和PropertyID必須有一個唯一的約束 - 如果需要索引的話，就這樣做吧。 – 2009-05-25 23:48:21
一種替代方法是使用所謂的代理鍵（偶爾也可以指定爲主鍵）。
例如，添加可用於唯一標識表中每行的標識列，即主鍵。
瞭解一個GUID用於在SQL Server中全局標識一條記錄（可以說這不是一個關係正確的做法，但這不是我們這裏的問題）。
標識列現在也是主鍵可以/將應用聚簇索引。然後可以將一個單獨的非聚集索引應用於原始海報描述的複合關鍵字。
這種做法避免了聚集索引內出現的頻繁頁面拆分問題（插入到一個隨機的GUID主鍵中）以及生成更小更高效的聚集索引，同時還保留了數據庫中定義的關係。
還有就是使用順序GUID的選項（NEWSEQUENTIALID，它也有侷限性，因爲你不能直接調用它的功能。）作爲Marc_s曾表示它是一個好主意，因爲它將被包含在任何非羣集鍵中。 – GrumpyMonkey 2009-05-24 21:34:04