mysql数据库自增主键弊端_数据库自增主键可能产生的问题

在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....