如果我在guid列上使用了主鍵，我該如何提高性能？

我得到了一個有50萬行的表。如果我在guid列上使用了主鍵，我該如何提高性能？

主鍵是GUID列。

我發現查詢select * from T where id ='xxxx'是很慢的。

我應該怎麼做，以提高性能？

來源

2011-04-18 dfang

如果可以，我想提出以下建議：

刪除現有主鍵 - 特別是如果它是聚集鍵，太（這是它在默認情況下）

添加新INT IDENTITY柱

ALTER TABLE dbo.YourTable ADD NewID INT IDENTITY(1,1)

使該INT字段初級/聚集鍵：

ALTER TABLE dbo.YourTable 
    ADD CONSTRAINT PK_YourTable PRIMARY KEY(NewID)

主鍵（或者更確切地說：聚集鍵）上的GUID列是一個可怕的想法，導致大量索引碎片，從而殺死你的選擇性能。

由於Kimberly Tripp - 索引的女王 - 和其他人已經說了很多次 - 作爲聚類鍵的GUID不是最佳的，因爲由於其隨機性，它將導致大量的頁面和索引碎片，並且通常糟糕的表現。

是的，我知道 - 在SQL Server 2005中有newsequentialid()及以上 - 但即使這不是真正的完全順序，因此也遭受與GUID相同的問題 - 只是稍微突出一點。

然後還有一個需要考慮的問題：表上的聚簇鍵將被添加到表上每個非聚簇索引中的每個條目上 - 因此，您確實希望確保它小到可能。通常情況下，具有超過250億行的INT應該足以滿足絕大多數表的要求 - 並且與GUID作爲集羣密鑰相比，您可以爲磁盤和服務器內存節省數百兆的存儲空間。

快速計算 - 使用INT與GUID作爲主要和聚集鍵：

基表與1'000'000行（3.8 MB與15.26 MB）
6個的非聚集索引（22.89 MB與91.55 MB）

總計：25 MB與106 MB - 這只是一個單一的表！

思考的一些更多的食物 - 金佰利特里普優秀的東西 - 讀它，看了一遍，消化它！這真是SQL Server索引福音書。

來源

2011-04-18 07:16:13

只是要清楚，這個建議和文章金伯利特里普在相關建議僅適用於在SQL Server羣集索引 - 在原始問題中沒有提到的東西。聚集索引與PRIMARY KEY不是同一個事物，並且不確定SQL Server是否是此處使用的DBMS。我提到這一點是因爲建議「放棄現有主鍵」本身並不是一個明智的建議，因爲您的主鍵恰好是一個GUID--而不是如果您重視該列的唯一性！ – sqlvogel 2011-04-18 12:55:01

@dportas：yes，true - 但是默認情況下，SQL Server **中的主鍵是集羣密鑰** - 除非您明確指出**並非**使其成爲集羣密鑰。我猜在至少85％的情況下，PK = CK – 2011-04-18 13:25:43

@marc_s，我會更精確地這樣說：聚簇密鑰正是您在創建聚簇密鑰時所選擇的。同上主鍵。關鍵和索引是不同的東西，我認爲這不是一個好主意，鼓勵兩者之間的混淆，特別是當OP詢問前者而不是後者時。 – sqlvogel 2011-04-18 13:31:55

如果我在guid列上使用了主鍵，我該如何提高性能？

回答

相關問題