做項目時發現我們項目居然是直接用時間戳做為自定義主鍵，導致批量新增時報錯，就查了一波自定義主鍵策略，集眾家之所長，匯成這篇文章。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.數據庫管理系統自增長主鍵策略
優點：簡單，不需要程序特別處理。字段長度小，占用存儲空間小，無論是在內存還是硬盤上。類型為數字類型，方便內部的比較和排序，對於查找有優勢。如果同時也將其建立為聚集索引，那么其他列上的非聚集索引所需存儲的內容會更少。由於其順序增長，磁盤碎片少。
缺點：這種方法對以后如果項目移植到其他數據庫上改動會比較大，oracle和db2采用Sequence，mysql和sqlserver采用自增長，通用性不強。僅為代理鍵，無實際意義。
（對於系統中大部分實際的業務功能采用1的自增長策略，這樣可以減少開發工作量，並且性能和並發都有保障。如果項目需要進行移植，業務功能這部分則會有變動，做二次開發可暫時不考慮移植性。如果數據不會刪除可以考慮使用自增列，如果會刪除且刪除頻繁則會造成主鍵的極大浪費。）
2.時間戳+隨機數
優點：實現簡單，與數據庫無關，移植性較好。
缺點：長度太大，最少也得20位，不僅占空間並且建立索引的話性能較差。
（對於某些流水、日志類的表可采用時間戳+隨機數，時間戳做主鍵會更有意義。但是當並發比較大時，此方案無法保證不重復，而一個系統中也就幾個功能並發會較大，對這些並發大功能的可以使用其他主鍵生成策略，如uuid，不過uuid生成的id太長）
3.每次取主鍵最大值+1作為新的主鍵
優點：主鍵長度可控，移植性較好。
缺點：並發寫可能會造成主鍵沖突，不便於控制並發。
（項目基礎功能部分，例如菜單功能管理，用戶管理，權限管理，機構組織管理，參數管理等采用此方案合適，這些功能一般數據量不大，基本沒有大的性能問題和並發問題，進行移植改動較小。單個jvm下堪用，分布式環境下此方案不通）
4.單獨建一個存放主鍵的表
優點：實現簡單，移植性較好。
缺點：需要考慮並發問題，整個系統主鍵生成都依賴該表，性能影響可能較大。