MySQL数据库自增主键可能产生的问题

自增主键 
这种方式是使用数据库提供的自增数值型字段作为自增主键，它的优点是： 
（1）数据库自动编号，速度快，而且是增量增长，按顺序存放，对于检索非常有利； 
（2）数字型，占用空间小，易排序，在程序中传递也方便； 
（3）如果通过非系统增加记录时，可以不用指定该字段，不用担心主键重复问题。 
其实它的缺点也就是来自其优点，缺点如下： 
（1）因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其它系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）。特别是在新系统上线时，新旧系统并行存在，并且是异库异构的数据库的情况下，需要双向同步时，自增主键将是你的噩梦； 
（2）在系统集成或割接时，如果新旧系统主键不同是数字型就会导致修改主键数据类型，这也会导致其它有外键关联的表的修改，后果同样很严重； 
（3）若系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个字符标识（例如“o”，old）来表示这是老数据，那么自动增长的数字型又面临一个挑战。

 

在MySQL中经常会配置自增长属性的字段作为主键，特别是使用InnoDB存储引擎，

因为InnoDB的聚集索引的特性，使用自增长属性的字段当主键性能更好，但是使用自增主键也可能会带来一些问题。
举个例子，使用自增主键对数据库做分库分表，可能出现一些诸如主键重复等的问题，或者在数据库导入的时候，可能会因为主键出现一些问题。

主要业务表的主键应该配置一个合理的策略，尽量避免自增AUTO_INCREMENT。

（1）依赖数据库自增机制达到全局ID唯一
使用如下语句：
REPLACE INTO Tickets64 (stub) VALUES ('a'); 
SELECT LAST_INSERT_ID();
这样可以保证全局ID唯一，但这个Tickets64表依旧是个单点。

（2）依赖数据库自增机制达到全局ID唯一并消除单点
在2的基础上，部署两个（多个）数据库实例，
设置自增步长为2（多个则为实例数），即auto-increment-increment = 2
设置auto-increment-offset分别为1,2.....
这样第一台数据库服务器的自增id为 1 3 5 7 9
第二台为2 4 6 8 10

（3）解决每次请求全局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....