有点懵！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也不满足我的需要怎么办呢？
如果bigint真的还不够使用的话，我们可以使用雪花算法生成的id做主键，由于其也是大致递增的，对性能也不会产生影响，只需要由bigint改成更大范围的decimal就行。
另外多说几句，建表时采用什么类型的主键，还是要根据具体业务具体分析，合理的主键类型会占用更小的空间，具有更好的性能。毕竟bigint占用8个字节，比int多了一倍呢。
写文不易，感谢您的点赞和关注。