在建立資料庫的時候，需要為每張表指定乙個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組，乙個表只能有乙個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行資料更新、刪除的時候不會出現張冠李戴的錯誤。資料庫的主鍵生成有多種方式，每種方式都有其優點和缺點，應該根據不同的需求在主鍵的時間和空間效率上做平衡折中，從而選擇不同的主鍵生成策略。歸納起來，對主鍵的選擇主要有以下四種方式：
1. 自動增長字段
自動增長型字段允許我們在向資料庫新增資料時，不考慮主鍵的取值，記錄插入後，資料庫系統會自動為其分配乙個值，確保絕對不會出現重複。
2. 手動增長字段
手動增長型的字段，也就是說主鍵的值需要自己維護，通常情況下需要建立一張單獨的表儲存當前主鍵鍵值。
3. guid型別
guid是globally unique identifier的縮寫，是乙個128位的隨機數,並保證不產生重複。
4. comb型別
comb（combine）型可以理解為一種改進的guid，它通過組合guid和系統時間，以使其在索引和檢索事有更優的效能。
下表列出四種主鍵生成方式優缺點的比較：
主鍵生成策略
優點缺點
自動增長字段
1.使用簡單
1.不同資料庫獲取當前值方式不同；
2.難以應用在多個資料庫間進行資料遷移的情況。
手動增長型字段
1.可以獲得最新鍵值
2.可以確保資料合併過程中不會出現鍵值衝突
1.通常情況下需要建立一張單獨的表儲存當前主鍵鍵值；
2.增加一次資料庫訪問來獲取當前主鍵鍵值；
3.考慮併發衝突等，增加系統的複雜程度。
使用guid
1.直接生成
guid
，獲得最新鍵值以填充主鍵，使用方便；
2.可以確保資料合併過程中不會出現鍵值衝突；
3.避免了前兩種方式獲取當前鍵值所增加的開銷。
1.占用較多儲存空間；
2.索引耗時；
3.在多表鏈結查詢時效率不如
int型
使用「comb」
型別1.
保留guid
的已有優點；
2.利用時間資訊與
guid
組合起來，增加有序性以提高索引效率。
1.需要設計
comb
的生成演算法；
2.和guid
一樣占用較多儲存空間；
3.在多表鏈結查詢時效率不如
int型，但優於
guid
。comb型別主鍵生成實現:
comb
資料型別的基本設計思路是這樣的：既然
guid
資料因毫無規律可言造成索引效率低下，影響了系統的效能，那麼能不能通過組合的方式，保留
guid的10
個位元組，用另
6個位元組表示
guid
生成的時間（
datetime
），這樣我們將時間資訊與
guid
組合起來，在保留
guid
的唯一性的同時增加了有序性，以此來提高索引效率。
在nhibernate
中，comb
型主鍵的生成**如下所示：
1
資料庫主鍵生成策略
在建立資料庫的時候，需要為每張表指定乙個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組，乙個表只能有乙個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行資料更新 刪除的時候不會出現張冠李戴的錯誤。資料庫的主鍵生成有多種方式，每種方式都有其優點和缺點，應該根據不同的...
mysql的主鍵策略 談資料庫主鍵選取策略
int和guid，究竟選誰？如小標題，如果真要選，我會選誰？肯定地說，我會選guid，又或者兩者都選上。後者情形下，使用guid做主鍵 int做小二，int在業務層生成，這要即使重複了，也不礙事，且int是要反饋給前端的，定時做乙個防衝突檢測。如果讓使用者記憶或反饋那guid字串 去連線字元後32位...
談資料庫主鍵選取策略
int和guid，究竟選誰？關於資料庫主鍵的選取策略，大家都是在int和guid兩者中徘徊。忘了那些喋喋不休的爭論吧！畢竟魚與熊掌，不可兼得。在這篇文章中，我們不再關注它們的優缺點，自覺先行做點功課哦！如小標題，如果真要選，我會選誰？肯定地說，我會選guid，又或者兩者都選上。後者情形下，使用gui...