主鍵生成策略

1.資料庫管理系統自增長主鍵策略

優點：簡單，不需要程式特別處理。字段長度小，占用儲存空間小，無論是在記憶體還是硬碟上。型別為數字型別，方便內部的比較和排序，對於查詢有優勢。如果同時也將其建立為聚集索引，那麼其他列上的非聚集索引所需儲存的內容會更少。由於其順序增長，磁碟碎片少。

缺點：這種方法對以後如果專案移植到其他資料庫上改動會比較大，oracle和db2採用sequence，mysql和sqlserver採用自增長，通用性不強。僅為**鍵，無實際意義。

（對於系統中大部分實際的業務功能採用1的自增長策略，這樣可以減少開發工作量，並且效能和併發都有保障。如果專案需要進行移植，業務功能這部分則會有變動，做二次開發可暫時不考慮移植性。如果資料不會刪除可以考慮使用自增列，如果會刪除且刪除頻繁則會造成主鍵的極大浪費。）

2.時間戳+隨機數

優點：實現簡單，與資料庫無關，移植性較好。

缺點：長度太大，最少也得20位，不僅佔空間並且建立索引的話效能較差。

（對於某些流水、日誌類的錶可採用時間戳+隨機數，時間戳做主鍵會更有意義。但是當併發比較大時，此方案無法保證不重複，而乙個系統中也就幾個功能併發會較大，對這些併發大功能的可以使用其他主鍵生成策略，如uuid，不過uuid生成的id太長）

3.每次取主鍵最大值+1作為新的主鍵

優點：主鍵長度可控，移植性較好。

缺點：併發寫可能會造成主鍵衝突，不便於控制併發。

（專案基礎功能部分，例如選單功能管理，使用者管理，許可權管理，機構組織管理，引數管理等採用此方案合適，這些功能一般資料量不大，基本沒有大的效能問題和併發問題，進行移植改動較小。單個jvm下堪用，分布式環境下此方案不通）

4.單獨建乙個存放主鍵的表

優點：實現簡單，移植性較好。

缺點：需要考慮併發問題，整個系統主鍵生成都依賴該錶，效能影響可能較大。

總結：

接觸單獨設計乙個存放主鍵值的表，有點是可移植，而且適用分布式系統，無需考慮多台機器併發向db中寫入資料時造成的主鍵衝突問題，但效能受限於db對這張表的併發處理。

在記錄日誌時，使用的是時間戳，精度到s級，果然出現主鍵衝突的錯誤，在加上隨機數之後解決。