MySQL自增主键id用完了怎么办？

前几天有个朋友出去面试，被面试官问到MySQL自增主键id用完了怎么办？由于对这块了解不多，所以回答得不太理想。

本篇文章为大家分享一下，MySQL自增主键达到上限以后会发生什么情况？该如何解决这种情况？

我们在定义MySQL表时，为了性能考虑，一般会使用MySQL的自增主键id，每个自增id都会定义一个初始值，一般从1开始，然后不停得增加步长（不配置的话步长默认为1）。

但是不知道大家考虑过没有，我们定义的int或者bigint都是有长度上限的。

如果表中的最大记录id超过这个上限值，MySQL会发生什么错误呢？

从上图可以看出，tinyint和smallint的范围都比较小，我们一般不会将其作为主键id的类型。

如果主键采用有符号int类型进行自增，那么id的最大值是2147483647，如果采用无符号int类型进行自增，那么id的最大值是4294967295。

以无符号int类型为例，42亿虽然看起来是个很大的数字，但是对于一些插入删除很频繁的业务来说，并非无法触达这个上限。

特别是有的业务表设置的步长比较大，会导致id自增的速度更快。

首先，我们来验证一下，当MySQL的自增主键达到最大值后，再往表中插入数据会出现什么现象？

新建一张表，并且直接指定最大自增值为4294967295。

CREATE TABLE t_max( id int unsigned auto_increment PRIMARY KEY ) auto_increment = 4294967295;

执行几次以下sql看看会出现什么结果。

INSERT t_max ( id ) VALUES ( NULL );

可以看到，直接提示主键重复了。

这里我们也可以验证MySQL的主键策略：id自增值达到上限以后，再申请下一个 id 时，仍然是最大值。

所以，如果你的业务预期会产生很多数据，那么建议你在创建表时，直接使用bigint，无符号的bigint最大值是18446744073709551615，这个数基本可以保证你的业务不受影响了。

当然，如果主键需要对外展示，为了安全考虑，大家也可以采用雪花算法生成的主键值，雪花算法产生的值和bigint一样都占用8个字节，并且是大致递增的，对性能也不会产生影响。

另外多说几句，建表时采用什么类型的主键，还是要根据具体业务具体分析，合理的主键类型会占用更小的空间，具有更好的性能。毕竟bigint占用8个字节，比int多了一倍呢。