MySQL自增id用尽怎么办？从原理到实战的完整自救指南

"线上MySQL的自增id用尽怎么办？"这个问题，基本是每个后端开发或者DBA迟早会撞上的事情。尤其当你负责的系统跑了一两年，业务量上来之后，某天深夜突然收到告警，说某张核心表的自增主键快到头了，那个瞬间确实有点后背发凉。虽然网上有很多讨论，但大多停留在"int换成bigint"这种层面。真到了线上，你会发现事情没那么简单：表已经几个亿数据了，直接改表结构可能锁表；就算你改了主键类型，如果没搞清楚自增id的分配机制，下一个坑还在后面等着。这篇文章我就把自增id耗尽这件事从原理到实操完整梳理一遍，结合我实际处理过的故障案例，讲清楚为什么它会耗尽、耗尽时会发生什么、以及在不同业务场景下该怎么安全地度过危机。

1. 自增id为什么会“用尽”：从小数轴到真实容量边界

要搞懂这个问题，先得知道自增id的本质。MySQL里用AUTO_INCREMENT修饰的列，本质是一个计数器，每次插入新行时自动加1。这个计数器有上限，上限取决于你定义列时用的整数类型。

MySQL的整数类型有TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，占用字节数分别是1、2、3、4、8。我们最常用的是INT和BIGINT。INT占用4字节，有符号范围是-2147483648到2147483647，无符号范围是0到4294967295。BIGINT占用8字节，有符号上限是9223372036854775807，无符号上限是18446744073709551615。

关键是很多人在建表时下意识写id INT AUTO_INCREMENT PRIMARY KEY，默认就是有符号INT，上限21.47亿。你可能觉得21亿很多了，但互联网业务的数据量增长往往是超预期的。一个日活百万的产品，用户行为表、订单表、日志表，一天几百万甚至上千万条插入很正常，21亿的上限大概也就是一两年的空间。更恐怖的是，一旦你用了INT UNSIGNED，上限翻倍到42.9亿，看着安全了些，但本质上还是在一个有限数字里打转，早晚会见底。

还有一点容易被忽略：MySQL对自增id的使用不是绝对连续的。这和innodb_autoinc_lock_mode参数有关，在默认模式（1）下，批量插入时自增id会跳跃分配；就算单条插入，只要发生过事务回滚，那个自增id就被消耗掉了，MySQL不会回填。所以表的自增id实际增长速度通常比你的业务插入行数更快，不要把上限和业务量做简单的一比一估算。

从工程角度来说，核心问题不是“21亿够不够大”，而是“这个列到底能容纳多少行、够用多久”。如果你预估自己的核心表月增500万行，那么INT上限够你跑三年多；但如果月增过亿，可能半年后就要开始焦虑了。所以做容量规划时，自增id的余量评估应该和磁盘容量评估一起做，而不是等告警响了才去看。

2. 症状识别：自增id耗尽时的数据库行为和典型报错

自增id耗尽不是一瞬间把表锁死，而是有前兆的。最典型的前兆来自information_schema.tables里的AUTO_INCREMENT字段，它记录了每张表下一个将要分配的自增值。如果你写个巡检SQL扫一遍全库，就能提前看到哪些表离上限很近了。

真正耗尽的那一刻，表现是插入失败。比如你的表定义是id INT AUTO_INCREMENT PRIMARY KEY，当前自增值已经是2147483647，那么下一次插入时，MySQL尝试分配2147483648，但这个值超出了INT有符号范围，于是直接报错。错误信息通常类似：

code复制ERROR 1062 (23000): Duplicate entry '2147483647' for key 'PRIMARY'

注意这里非常迷惑人——它报的是Duplicate entry，而不是Out of range。很多新手甚至老手第一次遇到都会以为是自己插入了重复主键，然后跑去查表里是不是真有这条记录，结果发现没有，然后反复重试，折腾半天才反应过来是自增id到头了。

为什么MySQL不自报一个“自增id耗尽”的错误？这是历史原因。MySQL在计算下一个自增id时，会尝试往整数类型的最大值+1方向走，这个值如果超出类型范围，内部会截断成这个类型的最大值。于是插入时发现主键冲突（因为已有行占用了这个最大id），就报了Duplicate entry。所以这个报错极具误导性，我见过有团队因为这个错误判断，去删了线上最大id的数据，结果越删越乱——你删掉了那条记录，自增值还是不会回退到删掉的值以下，下次插入照样撞墙。

还有一种情况是自增id还没到类型上限，但你已经手动插入过接近上限的值，比如手工插入了一条id=2147483646的数据。这时候表里没有2147483647，但自增计数器已经跳到2147483647了。再插入新数据，如果MySQL分配的id正好撞上已有数据，同样会报Duplicate entry。这种情况属于“自增id空间碎片化”，排查起来比直接耗尽更痛苦。

另外要特别提醒：INT耗尽时表现是插入报错，但SELECT、UPDATE、DELETE都可能正常。这就会出现一种“看起来数据库没挂，但业务就是写不进去”的诡异状态。对线上业务来说，写不进去比直接宕机更可怕，因为报警系统可能只监控了数据库进程存活和慢查询，没监控写入失败率，结果业务侧大量报错，数据库侧看着却风平浪静。

3. 自救方案对比：改bigint、重置自增值、还是换主键策略

自增id耗尽后，常规的解决方案就那么几条。但每条都有限制条件，选错了照样翻车。我按推荐程度和适用场景逐个分析。

3.1 扩容列类型到BIGINT

这是最彻底的方案：把INT改成BIGINT，把有符号改成无符号也可以。一条ALTER TABLE ... MODIFY COLUMN就能解决。

听起来简单，实际执行时要注意几个大坑。

第一，原生的ALTER TABLE在MySQL 5.6之前是COPY算法，要重建整张表，锁表时间可能长达几十分钟甚至几小时。MySQL 5.6之后支持了INPLACE算法，但不是所有操作都能走INPLACE。把INT改成BIGINT属于列类型变更，5.6之后实际上仍需要重建表，因为数据文件里的行格式要变化。在MySQL 8.0里，官方文档写明INT到BIGINT的变更不支持INPLACE，会用INSTANT或者COPY，实际测试下来基本是COPY。

第二，表几个亿数据时，直接ALTER会带来巨大的IO压力、主从延迟和锁竞争。所以我强烈建议不要在生产环境直接执行原生ALTER。

我常用的做法是用gh-ost或者pt-online-schema-change这类在线DDL工具。它们通过创建影子表、增量同步binlog的方式，把表结构调整变成后台任务，对线上影响降到最低。gh-ost需要一个能连上数据库的账号，还要有binlog权限，执行过程大概是这样：

bash复制# 以gh-ost为例，把test库的user表的id列从INT改为BIGINT
gh-ost \
--host=127.0.0.1 \
--user=dba \
--password=xxx \
--database=test \
--table=user \
--alter="MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT" \
--execute

gh-ost会在执行期间同步所有增量变更，最后在某个时间点进行原子切换。整个过程对线上基本无感，但要注意：它会在原表上加一个rename操作，如果业务里使用了触发器、外键，可能需要额外处理；而且执行期间要预留足够的磁盘空间，因为影子表会占用额外空间。

改完BIGINT之后，自增上限变成1844亿亿，这个量级对绝大多数业务来说，基本等于永久够用了。这也是我推荐的终极解法。

3.2 删除历史数据、重置自增值

有人想：我表里虽然数据多，但删掉大部分过期数据，自增id不就空出来了吗？这里有一个常见的误区：DELETE删除数据后，AUTO_INCREMENT值不会自动回退。MySQL的自增计数器一旦涨上去，就不会因为删行而变小。

要回退，只能手动指定一个较小的自增值：

sql复制ALTER TABLE user AUTO_INCREMENT = 1000;

前提是你知道表里当前最大的id是多少，设置的值必须大于当前最大id，否则MySQL会忽略这条语句并自动调整为max(id)+1。

那这个方案能不能用？只能说适用于极少数场景：比如你那张表的数据可以全清（比如临时表、缓存表），或者业务允许把主键全部重排。我曾经处理过一个案例：某张日志表有1.2亿条数据，主键是INT，已经跑到了20亿，但其实产品业务逻辑上只关心最近三个月的日志。当时我们先把三个月前的数据导出归档，然后TRUNCATE整张表（TRUNCATE会重置自增值），再导回三个月内的数据。这样数据量从1.2亿降到3000万，自增id从20亿回到3000万，不用动表结构就把问题解决了。但这个方案能成立，核心在于业务能接受主键变化、日志数据不是外部系统的关联依据。

如果你删了数据之后又插入了新数据，自增id会接着之前的值继续走，不会复用你删掉的那些值。所以“删数据再重置自增”本质上只适用于能清空整张表的场景。

3.3 改业务逻辑，主键改UUID或雪花ID

有些团队会想换个思路：不用自增id做物理主键，改用业务主键（比如订单号、UUID、雪花ID）。这样就把自增id的耗尽风险和主键解耦了。

这个思路本身没错，但只适合新系统，不适合已经在线上运行的自增id表。因为已经存在的表，所有索引、关联查询、分库分表路由可能都基于这个自增id。你改成UUID，意味着所有旧数据的主键要重写，外键引用要全部更新，这就是一次重构级别的大工程。

更合理的做法是：新业务表从一开始就不要用有业务含义的自增id作为主键，改用雪花ID或者类似全局唯一ID。自增列保留，但只作为排序或者内部标识用，不作为业务关联键。这样即使自增id耗尽，也不会影响业务查询，只是插入会报错。当然这依然需要处理耗尽问题，但至少不会牵一发而动全身。

对现有的自增id表来说，我的建议是老老实实走3.1节，BIGINT才是正道。

3.4 利用负数空间续命

这个方案比较取巧。如果你的表主键是INT有符号类型，它的范围是-2147483648到2147483647。因为业务一直用正数，负数空间完全空着。理论上你可以通过手动指定主键的方式，将负数空间利用起来。

比如当自增id撞到2147483647时，马上执行：

sql复制INSERT INTO user (id, name) VALUES (-1, 'test');

然后继续用负数插入。但这里有个致命问题：MySQL的自增计数器不会自动跳到负数区间。你手动插入负数后，自增计数器仍然停留在2147483647，下一条普通插入还是会报错。如果你想让自增id自动去用负数空间，得临时把AUTO_INCREMENT的值设置成负数：

sql复制ALTER TABLE user AUTO_INCREMENT = -100;

这样MySQL分配的自增id会从-99开始递增。但这意味着你所有的自增id都变成负数，如果你的代码里、接口文档里、前端页面里任何地方对这个id有“必须大于0”的假设，全都会炸。而且负数id在分页、排序、缓存key前缀等场景下很容易出隐藏bug。

我的评价是：这只能作为“极端情况下修复线上报表写入”的应急手段，而且必须在业务代码完全不受负数影响的前提下才能用。术上可行，但常规情况下不推荐。

4. 比主键更隐蔽的“自增资源”：row_id、Xid、thread_id那些坑

正主键耗尽已经够麻烦了，但MySQL内部还有几个自增资源，它们耗尽时的表现更隐蔽，也不容易恢复。这部分可能是很多运维同学的知识盲区。

4.1 InnoDB隐藏row_id

如果你建表时没有显式指定主键，InnoDB会给你生成一个隐藏的row_id，它是全局共享的，所有没有主键的表共用一个计数器。这个row_id用6字节存储，最大到2^48-1（281474976710655）。

听起来很大，但它不是按单表算的，而是所有无主键表共用的。一旦超过上限，row_id会从0重新开始。这时候如果之前已经有数据占用了这个row_id，新插入的数据会覆盖旧数据。因为row_id在聚簇索引里是唯一的，复用同一row_id意味着新旧两行映射到同一个物理位置，旧数据直接消失。这个故障的表象是“数据莫名其妙的丢失”，极难排查，而且无主键表在binlog模式下主从复制也不安全。所以我的建议很直接：任何生产环境表都建显式主键，哪怕用业务唯一键也行。这条底线不能破。

4.2 事务ID（Xid）

InnoDB内部事务ID是一个64位整数，由trx_sys维护。当它达到上限后会回绕到0重新开始。事务ID回绕本身不会直接报错，但可能导致MVCC判断混乱：旧版本的判断逻辑会认为一些新事务是旧事务，从而产生不可见数据。好在这个数值是2^64量级，实际业务几乎不可能触发。但理论上如果触发，修复难度极大，基本只能重建实例。

4.3 thread_id

MySQL线程ID也有限制，它存储在thread_id_t类型里，最大到2^32-1。连接数一般不会到2^32，所以这个基本不用操心。

我列个表总结一下这些自增资源的关键信息：

说实话，后面几类资源普通人一辈子都碰不到，但我还是想写出来。因为一旦碰到，基本就是P0级事故，而有这个意识的人，往往能在建表阶段就规避掉最大的那个坑。

5. 把“id耗尽”拦在发生之前：巡检SQL、告警阈值与容量评估

处理完了眼前的自增id危机，更重要的课题是如何防止以后再犯。这一步拼的是日常运维的功夫。

5.1 一条SQL摸清全库自增余量

我先贴一个我日常巡检用的SQL，它可以一次性查出来所有表的自增id使用情况：

sql复制SELECT
  t.TABLE_SCHEMA,
  t.TABLE_NAME,
  t.AUTO_INCREMENT,
  CASE
    WHEN c.DATA_TYPE = 'tinyint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 255
    WHEN c.DATA_TYPE = 'tinyint' THEN 127
    WHEN c.DATA_TYPE = 'smallint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 65535
    WHEN c.DATA_TYPE = 'smallint' THEN 32767
    WHEN c.DATA_TYPE = 'mediumint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 16777215
    WHEN c.DATA_TYPE = 'mediumint' THEN 8388607
    WHEN c.DATA_TYPE = 'int' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 4294967295
    WHEN c.DATA_TYPE = 'int' THEN 2147483647
    WHEN c.DATA_TYPE = 'bigint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 18446744073709551615
    WHEN c.DATA_TYPE = 'bigint' THEN 9223372036854775807
    ELSE NULL
  END AS max_id,
  ROUND(
    (t.AUTO_INCREMENT / (
      CASE
        WHEN c.DATA_TYPE = 'tinyint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 255
        WHEN c.DATA_TYPE = 'tinyint' THEN 127
        WHEN c.DATA_TYPE = 'smallint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 65535
        WHEN c.DATA_TYPE = 'smallint' THEN 32767
        WHEN c.DATA_TYPE = 'mediumint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 16777215
        WHEN c.DATA_TYPE = 'mediumint' THEN 8388607
        WHEN c.DATA_TYPE = 'int' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 4294967295
        WHEN c.DATA_TYPE = 'int' THEN 2147483647
        WHEN c.DATA_TYPE = 'bigint' AND c.COLUMN_TYPE LIKE '%unsigned%' THEN 18446744073709551615
        WHEN c.DATA_TYPE = 'bigint' THEN 9223372036854775807
        ELSE NULL
      END
    )) * 100,
    2
  ) AS id_usage_percent
FROM information_schema.tables t
JOIN information_schema.columns c
  ON t.TABLE_SCHEMA = c.TABLE_SCHEMA
 AND t.TABLE_NAME = c.TABLE_NAME
WHERE c.EXTRA = 'auto_increment'
  AND t.TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY id_usage_percent DESC;

这条SQL会把所有带自增列的表的使用百分比算出来，你可以在定时任务里跑，把id_usage_percent超过80%的表输出到告警系统。

有一点要提醒：information_schema.tables.AUTO_INCREMENT的值并不是实时精确的，它有时候会滞后，有时候在表完全空闲时才更新。所以它更适合用来做趋势监控，而不是精确判断“下一秒会不会撞顶”。真要精确判断，得通过SHOW CREATE TABLE或者直接查内存中的自增计数器，但对日常巡检来说，information_schema的数据已经够了。

5.2 告警阈值设置经验

阈值怎么设？我一般分两档：

• 使用率到了70%，就把这张表列入“需关注”清单，发给研发确认业务增长趋势，评估剩余可用时间。
• 使用率到了85%，进入“待处理”状态，开始讨论改BIGINT的方案和执行窗口。
• 使用率超过95%，就是紧急状态，需要尽快执行在线表结构变更。

为什么不等到99%再动手？因为在线DDL工具执行需要时间，gh-ost处理上亿行的表可能要几十分钟到几小时。而且执行期间如果遇到业务大促、流量高峰，你还得暂停。所以留足提前量非常重要。另外不同表的增长速度差异很大，一张热度表一个月能吃掉10%的余量，另一张冷表五年都没怎么动。所以除了看当前使用率，还要结合近N个月的增速做趋势预测。

5.3 新表设计规范

比起事后补救，最好的策略是提前定好建表规范。我在团队里推的规矩很简单，就两条：

第一，所有新表主键一律BIGINT UNSIGNED AUTO_INCREMENT。除非有极其特殊的理由，否则不要用INT/UUID做物理主键。BIGINT的存储空间比INT多4字节，对单表几千万行的量级来说，多出来的那点空间完全可接受，但换来的却是几十亿倍的id空间余量。

第二，如果业务需要对外暴露唯一ID，不要在数据库主键上直接做文章。可以把主键当成内部标识，对外另加一个biz_id字段，用雪花算法或者其他分布式ID生成器填充。这样就算未来主键策略调整，对外接口完全不受影响。很多大厂在做分库分表时不也是这样的思路吗？数据库主键和业务ID分离，这个习惯越早养成越好。

5.4 最后的检查单

如果发现自己已经踩进了自增id用尽这个大坑，按这个顺序处理：

1. 先确认报错是不是自增id耗尽导致的：查information_schema.tables.AUTO_INCREMENT，看它是否接近当前列类型上限。
2. 评估业务影响面：如果是核心写表，立即告知业务方暂停低优先级写入；如果是日志表，可以考虑直接切换备表写入。
3. 从3.1到3.4里选一个适合自身场景的方案，优先BIGINT扩容，用gh-ost执行。
4. 执行完成后，验证自增值和新写入是否正常：插入一条测试数据，查看AUTO_INCREMENT是否跳到了新值。
5. 复盘：把这张表的增长速率、剩余空间纳入监控，并同步更新建表规范，避免其他表重蹈覆辙。

这些步骤做完，一次自增id耗尽事故算是真正闭环了。但说句实在话，我处理过好几起类似故障，最深的感觉是：自增id耗尽这种事，技术难点其实不在“怎么改”，而在“怎么不慌”。只要平时把巡检做到位、把应急方案提前准备好，真到了那一刻，按流程执行就好。怕就怕平时觉得“表数据量不大不用管”，结果某天深夜告警炸了，你连gh-ost是干什么的都忘了，那才是真正的灾难。