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