在MySQL中经常会配置自增长属性的字段作为主键,特别是使用InnoDB存储引擎,因为InnoDB的聚集索引的特性,使用自增长属性的字段当主键性能更好,但是使用自增主键也可能会带来一些问题。举个例子,使用自增主键对数据库做分库分表,可能出现一些诸如主键重复等的问题,或者在数据库导入的时候,可能会因为主键出现一些问题。主要业务表的主键应该配置一个合理的策略,尽量避免自增AUTO_INCREMENT。
针对主键自增可能产生的问题,下面这两篇文章有相关的讨论:
一、针对主键增长方式的解决方法
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包
com.eaio.uuid
uuid
3.2