在MySQL中經常會配置自增長屬性的字段作為主鍵，特別是使用InnoDB存儲引擎，因為InnoDB的聚集索引的特性，使用自增長屬性的字段當主鍵性能更好，但是使用自增主鍵也可能會帶來一些問題。
舉個例子，使用自增主鍵對數據庫做分庫分表，可能出現一些諸如主鍵重復等的問題，或者在數據庫導入的時候，可能會因為主鍵出現一些問題。主要業務表的主鍵應該配置一個合理的策略，盡量避免自增AUTO_INCREMENT。
針對主鍵自增可能產生的問題，下面這兩篇文章有相關的討論：
INNODB自增主鍵的一些問題
mysql自增列導致主鍵重復問題分析
一、針對主鍵增長方式的解決方法
1、設置主鍵自增為何不可取
這樣的話，數據庫本身是單點，不可拆庫，因為id會重復。
2、依賴數據庫自增機制達到全局ID唯一
使用如下語句：
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
這樣可以保證全局ID唯一，但這個Tickets64表依舊是個單點。
3、依賴數據庫自增機制達到全局ID唯一並消除單點
在2的基礎上，部署兩個（多個）數據庫實例，
設置自增步長為2（多個則為實例數），即auto-increment-increment = 2
設置auto-increment-offset分別為1,2.....
這樣第一台數據庫服務器的自增id為 1 3 5 7 9
第二台為2 4 6 8 10
4、解決每次請求全局ID都讀庫寫庫壓力過大的問題
比如第一次啟動業務服務，會請求一個唯一id為3559
如果是2、3的方法，則id為3559，這樣每次都請求數據庫，對數據庫壓力比較大
可以用3559 * 65536（舉個例子，並不一定是65536）+ 內存自增變量來作為id
當內存自增變量到達65535時，從數據庫重新獲取一個自增id
這樣即使有多台業務服務器，id也不會重復：
第一台 3559 * 65536 + 1,2,3.....65535
第二台 3560 * 65536 + 1,2,3.....65535
然后第一台到65535了，換一個數據庫自增id，這時候可能是3561 * 65536 + 1,2,3....
5、使用UUID
UUID目前有Version1-5 5個版本:
- Version1:基於時間的UUID,這個版本的UUID可以保證在全球范圍內的唯一性. 這個版本有60位的字節來表示時間,精確到納秒,因此基本上保證了時間上的不重復,並且最后還有48位字節的節點信息,是由MAC地址等硬件信息來表達的.中間的16位時鍾序列則用於避免其他信息改變(機器時間錯誤,MAC地址手動填寫沖突等)的情況下增加的一個隨機碼. 基本上可以說這個版本的UUID就可以滿足高並發的分布式系統下的UniqueID的唯一.
- Version2:DCE安全的UUID,這個版本的UUID的算法和Version1的是相同的,但是會把時間戳的前4位置換為POSIX的UID或GID.這個版本的UUID使用的比較少.
- Version3:基於名字MD5的UUID,這個版本的UUID通過計算名字和名字空間的MD5散列值而得到結果.這個版本的UUID保證了:相同命名空間中不同名字生成的UUID是唯一的,不同命名空間中的UUID的唯一性,但是相同名字空間中相同名字的UUID是可能會重復的.因此,一般不用作UniqueID的生成.
- Version4:這個版本也是使用的比較多的,也是JAVA中UUID.randomUUID()方法的實現規則.它不關心UUID的各個位置上的規則,直接使用SecureRandom生成16個隨機的字節.然后把第6個字節設置為Version4,把第8個字節設置為IETF標識.
- Version5:基於名字SHA1的UUID,這個版本的UUID算法和Version3的是一樣的,只是把名字和命名空間的散列算法改為了SHA1
從這幾個版本中可以看出,Version1和Version2是最適合於分布式計算環境下,具有高度唯一性的UniqueID,而Version3和Version5適用於一定范圍內名字唯一的情況.而Version4在分布式的情況下,最好不要用,雖然是隨機的,但是說不准在高並發的情況下,就有可能重復. 因此,如果要在JAVA中生成Version1的UUID,可以使用以下這個jar包
<dependency>
<groupId>com.eaio.uuid</groupId>
<artifactId>uuid</artifactId>
<version>3.2</version>
</dependency>