关于数据库:面试官数据库自增ID用完了会怎么样

看到这个问题，我想起当初玩魔兽世界的时候，25H 难度的脑残吼的血量曾经超过了 21 亿，所以那时候正本的 BOSS 都设计成了转阶段、回血的模式，因为魔兽的血量是 int 型，不能超过 2^32 大小。

预计暴雪的设计师都没想到几个资料片下来血量都超过 int 下限了，以至于大家猜测才会有起初的属性压缩。

这些都是题外话，只是通知你数据量大了是有可能达到下限的而已，回到 Mysql 自增 ID 下限的问题，能够分为两个方面来说。

1. 有主键

如果设置了主键，并且个别会把主键设置成自增。

咱们晓得，Mysql 里 int 类型是 4 个字节，如果有符号位的话就是[-2^31,2^31-1]，无符号位的话最大值就是 2^32-1，也就是 4294967295。

创立一张表试试：

CREATE TABLE `test1` (`id` int(11) NOT NULL AUTO_INCREMENT,
    `name` varchar(32) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2147483647 DEFAULT CHARSET=utf8mb4;

而后执行插入

insert into test1(name) values('qq');

这样表里就有一条达到有符号位的最大值下限的数据。

如果再次执行插入语句：

insert into test1(name) values('ww');

就会看到谬误提醒：1062 - Duplicate entry '2147483647' for key 'PRIMARY', Time: 0.000000s。

也就是说，如果设置了主键并且自增的话，达到自增主键下限就会报错反复的主键 key。

解决方案，mysql 主键改为 bigint，也就是 8 个字节。

设计的时候要思考分明值的下限是多少，如果业务频繁插入的话，21 亿的数字其实还是有可能达到的。

2. 没有主键

如果没有设置主键的话，InnoDB 则会主动帮你创立一个 6 个字节的 row_id，因为 row_id 是无符号的，所以最大长度是 2^48-1。

同样创立一张表作为测试：

CREATE TABLE `test2` (`name` varchar(32) NOT NULL DEFAULT ''
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4;

通过 ps -ef|grep mysql 拿到 mysql 的过程 ID，而后执行命令，通过 gdb 先把 row_id 批改为 1

sudo gdb -p 2584 -ex 'p dict_sys->row_id=1' -batch

而后插入几条数据：

insert into test2(name) values('1');
insert into test2(name) values('2');
insert into test2(name) values('3');

再次批改 row_id 为 2^48，也就是 281474976710656

sudo gdb -p 2584 -ex 'p dict_sys->row_id=281474976710656' -batch

再次插入数据

insert into test2(name) values('4');
insert into test2(name) values('5');
insert into test2(name) values('6');

而后查问数据会发现 3 条数据是 4，5，6，3。

因为咱们先设置 row_id= 1 开始，所以 1，2，3 的 row_id 也是 1，2，3。

批改 row_id 为上限值之后，row_id 会从 0 从新开始计算，所以 4，5，6 的 row_id 就是 0，1，2。

因为 1，2 数据曾经存在，数据则是会被笼罩。

总结

自增 ID 达到下限用完了之后，分为两种状况：

1. 如果设置了主键，那么将会报错主键抵触。
2. 如果没有设置主键，数据库则会帮咱们主动生成一个全局的 row_id，新数据会笼罩老数据

解决方案：

表尽可能都要设置主键，主键尽量应用 bigint 类型，21 亿的下限还是有可能达到的，比方魔兽，尽管说 row_id 下限高达 281 万亿，然而笼罩数据显然是不可承受的。