關於數據庫自增主鍵的幾個問題

1 是否每張表都應該有自增主鍵？

不必定

自增主鍵能夠加快行的插入速度，對於表的空間利用上有優點，碎片化不明顯。

可是對一些內容，如根據uid的查詢很是頻繁的，並且比較集中的，那若是不用自增主鍵，而是使用uid+id做爲複合主鍵，那查詢效率會上去，但插入和碎片化就會增長。但若是數據庫的存儲類型是ssd，那這個問題就不存在了。

因此，大部分狀況來看，表有自增主鍵是正確的。

2 自增主鍵是否具備業務上的惟一性？

不必定

單表結構下，是的。

多表狀況下，不必定，須要必定的策略，如設定不一樣的後綴，相同的間隔等。

3 自增主鍵是否能夠牽扯到業務？

不建議這樣作。

如：表能夠有自增主鍵，表內是具備惟一性的。在根據id查詢和更新的時候，能夠簡化操做。但通常來講，和業務上存在關係，而且須要惟一性的時候，應該由業務自主去維護，如使用格式或算法，hash生成等方式。

4 業務維護的主鍵，怎樣在多表的狀況下保持惟一性？

維護自增鍵區間段，服務器每次取其中的一段，樂觀鎖更新。這個須要額外的表或策略來維護這個字段。

基於算法A，固定時間前綴，如：yyyyMMddHHmmss+表數mod值+隨機數，經過位數的增長，來下降衝突的可能性。表字段存在惟一性約束（但有時候這個約束並不可靠）插入時若拋出重複字段值異常，則從新生成插入。

基於算法B，固定時間前綴，如：yyyyMMddHHmmss+固定位數碰撞自增值N+隨機數。不須要經過位數的增長來下降衝突的可能性。當插入拋出重複字段值異常時，N++，從新插入，直到再也不衝突爲止。此後固定使用N做爲中綴，而且N緩存於服務器，重啓後繼續使用此中綴。若出現重複異常，再次N++執行相同操做便可。N的mod值這些就不用故意提起啦。

基於中綴管理，即上報中綴到中心服務器，能夠理解有地方緩存了服務器的id關係，動態分配中綴。

其餘方法，還有不少，也沒有用過，不贅述了。

 

算法B，簡單，通訊少，並且碰撞次數有限。算法A，存在無限次數的碰撞，儘管百分比很是很是低。可是在高併發的狀況下，初始化的時候，算法B會比算法A來得更暴風驟雨一些。

區間段和中綴管理，都引入了中心節點的概念，依賴性比較強，但相對可靠，業界更爲通用的實現方式。