前天發表了篇文章叫《小議數據庫主鍵選取策略（原創）》，隨即有網友提出了反駁意見《反駁 呂震宇的“小議數據庫主鍵選取策略（原創）” 》，看到后，我又做了做實驗，在這里將實驗結果以及我的思考再向大家匯報一下：

首先感謝twodays提出意見，說實在的，關于COMB與GUID的效率差異是否有10到30倍我沒有做實驗，我會在以后掌握確切數據后修改這個結果。twodays的實驗我做了，在我的機器上（P IV 2.0G，512M DDR400內存）實驗結果如下：

int類型為主鍵的表插入開始時間：07 19 2004? 8:19PM
int類型為主鍵的表插入結束時間：07 19 2004? 8:19PM
int類型為主鍵的表插入共用時間：5600毫秒
?
GUID(聚簇索引)類型為主鍵的表插入開始時間：07 19 2004? 8:19PM
GUID類型(聚簇索引)為主鍵的表插入結束時間：07 19 2004? 8:19PM
GUID類型(聚簇索引)為主鍵的表插入共用時間：6030毫秒?
?
GUID(非聚簇索引)類型為主鍵的表插入開始時間：07 19 2004? 8:19PM
GUID類型(非聚簇索引)為主鍵的表插入結束時間：07 19 2004? 8:19PM
GUID類型(非聚簇索引)為主鍵的表插入共用時間：5746毫秒?
?
COMB類型為主鍵的表插入開始時間：07 19 2004? 8:19PM
COMB類型為主鍵的表插入結束時間：07 19 2004? 8:19PM
COMB類型為主鍵的表插入共用時間：6066毫秒

從中看到似乎COMB是最慢的。但是這又有多少是因為計算COMB數據而造成的呢？

SET?@aGuid?=?CAST(CAST(NEWID()?AS?BINARY(10))?+?CAST(GETDATE()?AS?BINARY(6))?AS?UNIQUEIDENTIFIER)

而且，作為聚簇索引與非聚簇索引的概念，我想僅僅MSDN中的一段話是不足以說明問題的。我想從以下幾個方面重新論述一下：

一、主鍵的作用：

“反駁”中有這樣兩句話：“采用非聚簇索引也有不方便的地方，那就是不能排序了”，“如果只是為了需要一個唯一標示符來做為主鍵，并且在這個字段上不需要做什么排序呀，范圍對比等操作的話，那么我們可以放心大膽的使用GUID來做為主鍵”。那么主鍵的作用是什么呢？我認為主鍵有這么幾個作用：

• 實現實體完整性約束，確保不會出現重復；
  
• 在參照完整性中充當被參照對象，需要與外鍵進行連接，當然從優化角度出發也需要排序了；
  
• 在編程建立業務實體對象時，是一個很好的檢索出發點；
  
• 在刪除、更新操作時可以出現在WHERE短語中表示操作的對象（顯然又會進行檢索）。

所以，主鍵一個必不可少的功能就是排序，提高檢索效率。不過我認為“反駁”中有一點搞錯了，那就是在排序問題上，實際上非聚簇索引主鍵在排序上不輸給聚簇索引主鍵多少（這一點請看論述二）。

二、聚簇索引與非聚簇索引的本質區別是什么

因為“反駁”中僅僅做了插入實驗，所以我認為不足以說明問題。很多人并沒有真正了解聚簇索引與非聚簇索引的本質區別，以至于對實驗結果產生誤解。為此我新寫了一篇文章《聚簇索引與非聚簇索引的區別以及SQL Server查詢優化技術》，在這里詳細進行了論述，看完后，很多事情也就不言自明了。


三、應當如何設計實驗檢測COMB與GUID的效率問題

設計一個實驗應當能夠準確衡量被測試的內容，盡可能少的減少其它因素帶來的偏差。我認為“反駁”中的實驗僅僅測試了插入性能，而且沒有把計算COMB的造成的性能損失因素排除在外，另外主鍵與外鍵連接時的性能沒有測試，排序性能也沒有測試。昨天晚上我重新設計了實驗，并得到了新的實驗結果。實驗過程以及實驗結果會隨后公布（這兩天正在忙競聘）。

轉載于:https://www.cnblogs.com/zhenyulu/archive/2004/07/20/25816.html

總結

以上是生活随笔為你收集整理的再议《反驳 吕震宇的“小议数据库主键选取策略（原创）” 》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。