談資料庫主鍵選取策略

int和guid，究竟選誰？

關於資料庫主鍵的選取策略，大家都是在int和guid兩者中徘徊。忘了那些喋喋不休的爭論吧！畢竟魚與熊掌，不可兼得。在這篇文章中，我們不再關注它們的優缺點，自覺先行做點功課哦！

如小標題，如果真要選，我會選誰？肯定地說，我會選guid，又或者兩者都選上。後者情形下，使用guid做主鍵、int做小二，int在業務層生成，這要即使重複了，也不礙事，且int是要反饋給前端的，定時做乙個防衝突檢測。如果讓使用者記憶或反饋那guid字串（去連線字元後32位），可以直接去跳樓了！

int和guid，究竟誰快？

使用int或guid做主健，究竟誰更快？為回答這個問題，我們先看下面的**內容：

解釋一下：

1、uniqueidentifier儲存為二進位制值，為什麼是16位元組呢？0~f 共16 種表示，有16*16＝256，也有2^8=256（值域為0~255），去掉四個連線字元，即表示為16位元組。

2、varchar和nvarchar屬變長型，儲存時會增加乙個int型別（四個位元組）記錄內容長度。

3、nchar和nvarchar型別儲存為unicode資料，占用兩個位元組，所以位元組數要算雙份。

誰會更快？

1、勿庸置疑，int肯定是最快的，甚至你會選擇int而不是bigint。

2、其次，誰會更快？當選uniqueidentifier。

3、專案中，選用了varchar、nchar、nvarchar中某一型別？只怕你會是神，不是人或妖。

int和guid，誰主沉浮？

專案中，如果你是使用int做主健，那麼接下來的內容可以直接略過？因為你已經得到了答案。

寫這篇隨筆的主要目的，是要告訴大家，使用guid做主鍵時，特別要注意索引與排序問題。

guid做主鍵，字段型別為char(36)，資料記錄索引與排序依據肯定是字串的從左到右，即：12345678-0000-0000-0000-000000000000

guid做主鍵，字段型別為uniqueidentifier，資料記錄索引與排序依據將是後六位元組，即：00000000-0000-0000-0000-1234567890ab

為什麼會這樣？資料儲存為uniqueidentifier時，會體現為sqlguid 結構。

msdn描述有：sqlguid使用sqlserver行為實現compareto，該行為只計算值的最後6個位元組。guid 計算全部 16 個位元組。

結束語

為了驗證所說，你可以這樣做：建表並新增uniqueidentifier欄位型別，隨機插入幾萬條記錄，然後觀察後十二位字元的排序情況，或參考下面截圖。

***********************************=分割線******************************==