COMB guid的性能值

Jimmy Nilsson討論了他的COMB guid概念here。這個概念在NHibernate和其他圈子中很受歡迎，因爲它的性能價值超過了標準的GUID，而這些GUID通常更加隨機。COMB guid的性能值

但是，在測試中，這似乎並非如此。我錯過了什麼嗎？

測試用例：

我有一個表稱爲臨時（不是臨時表，只是一個名爲「TEMP」一表），在它585,000行。我有一個名爲Codes的新表，並且希望將所有585,000個代碼值從臨時表複製到代碼表。測試SQL我執行了：

set statistics time on; 

truncate table codes; 
DBCC DBREINDEX ('codes', '', 90); 

insert into codes (codeid, codevalue) 
select newid(), codevalue from temp 

truncate table codes; 
DBCC DBREINDEX ('codes', '', 90); 

insert into codes (codeid, codevalue) 
select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp

性能標準GUID值：

SQL Server的執行時間：CPU 時間= 17250毫秒，經過的時間= 15735 毫秒。

（585000行（S）的影響）

性能與COMB GUID值：

SQL Server的執行時間：CPU 時間= 17500毫秒，經過的時間= 16419 毫秒。

（585000行（S）的影響）

我缺少什麼？ COMB GUID值導致稍長的時間，大概是由於額外的轉換。我認爲重點是通過使用最後6個字節的日期對GUIDS進行半排序來減少插入時間，但性能增益似乎不存在。

來源

2009-07-20 Chris

難道我或任何回答可以滿足你的問題？ – gbn 2011-10-24 14:22:50

@Chris：gbn是否正確？ – jgauffin 2014-01-02 18:23:53

我第二次只有在Guid colume上有索引（PK，FK或其他類型的索引，集羣或非集羣）時纔會看到差異，因爲標準guid與newguid或comb guid的成本是由於每次執行插入操作時重新排序索引數據的成本很高。

見我的問題在我與一些現實生活中的數據證實了這一來自SQL Server和Oracle：StackOverFlow Question

問候馬西莫

來源

2010-09-09 12:05:03 massimogentilini

我建議你沒有看到訂單收益，因爲目標表沒有PK。所以，這是您看到的轉換開銷。如果它有一個PK，585k行仍然必須在插入時排序。 SQL如何知道它是半排序的？

現在，如果它是5,850 x 100行插入，那麼您可能會看到一些好處，因爲新行將「在最後」而不是「在中間」，從而減少頁面拆分和開銷。

我會進一步說，這篇文章是2002年的，是SQL 2000的，並且已經被現實生活所取代。

在SQL Server 2005中，我們有SEQUENTIAL GUID以允許嚴格單調的GUID來解決一些問題。作爲PK的GUID也在這裏完成：最近的例子：INT vs Unique-Identifier for ID field in database與第三方鏈接。

如果ORM將GUID指定爲PK而不是自然鍵或標準的基於int的替代鍵，那麼這是ORM的嚴重限制。客戶尾巴搖擺數據庫狗的情況。

來源

2009-07-20 19:50:08 gbn

-2

您的用於生成新GUID的代碼不正確。對於每一行，它都會創建一個非常不同的數字（您可以爲每行調用NEWID（））。您需要保持大部分GUID相同。

來源

2010-09-01 15:16:50

COMB guid的性能值

回答

相關問題