大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

去年帮一个团队看故障，订单表突然开始报主键冲突。开发说程序在重试，重试多了撞上重复键。我看了一眼表结构，`id INT NOT NULL AUTO_INCREMENT`，再看当前最大值，2147483647。这个数太有辨识度了，它就是 int 有符号的上限。那张表跑了七年，从零开始一格一格走到头，走到最后一天才开始报错。自增耗尽这件事最好玩的地方就在这：它在建表那天就注定了，只是账要七年后才结。

## 一、先算清上限

MySQL 的整数类型，上限是固定的。知道这张表一天写多少行，就能反推它还能跑多久。下面这张表可以直接对照，注意有符号和无符号差一倍。

|类型|有符号上限|无符号上限|日均100万行能撑多久|
|:-:|:-:|:-:|:-:|
|TINYINT|127|255|十几秒|
|SMALLINT|32767|65535|不到一小时|
|MEDIUMINT|8388607|16777215|八天|
|INT|2147483647|4294967295|五年十一个月|
|BIGINT|9223372036854775807|18446744073709551615|用不完|

`INT` 有符号是 21.47 亿。日均 100 万行的话，五年十一个月到顶。听着很久，可这套系统第七年才出事，说明前期量小，后面几年在加速。所以别用"平均日增"算，用最近三个月或者最近一个季度的日增算，那个数才是真的。

还有一个成倍消耗的坑：双主或者多写节点。两台都写，`auto_increment_increment` 设成 2，一台拿奇数一台拿偶数，21 亿的空间就只剩 10.7 亿。步长设置成 5，就只剩 4.3 亿。这个参数在建库时随手设的，做余量计算时最容易漏。

## 二、到顶之后会发生什么

不会突然全部停摆，表现分三种，一种比一种难查。

第一种是直接报错。插入时分配不到新号，MySQL 返回的是主键冲突，`1062 Duplicate entry '2147483647' for key 'PRIMARY'`。它每次都拿上限那个值去试，所以报出来的是重复键，不是"号用完了"。这个错还有人会误判成程序重试导致的重复提交，方向一偏，半天就过去了。

第二种是静默丢单。业务代码里有 `try...catch`，捕获异常记了一条日志，接口照样返回成功。用户以为下单成功，库里没有这行。这种最要命，等你发现的时候，缺口已经积累了几千单，还得靠对账一条条补。

第三种最隐蔽，是号段被复用。有人为了救火，把表清空、把 `AUTO_INCREMENT` 改回 1，想让号从头开始。表里还有数据的时候，这个 ALTER 根本不会生效，计数器只肯往上走；一旦表被清空，它就真的从 1 开始。空出来的号会被新数据占用，同一个 `id` 在缓存里、在日志里、在外部对账文件里指向两笔不同的业务，之后怎么查都对不上。号段一旦复用，历史数据的引用关系就断了，这件事比丢单更难收拾。

顺带说清版本差异。8.0 把自增计数器持久化进了 redo log，重启之后不会倒退，8.4 也一样。5.7 重启后会把计数器重置成 `max(id)+1`，如果最大值那几行被删了，重启就会复用已经用过的号。所以 5.7 的库更要注意，一次重启就可能埋一个雷。

## 三、余量怎么算

三条 SQL 就够，跑完把数记到巡检表里，每月看一次。

```
-- 1) 当前自增位与表的行数规模
SELECT TABLE_NAME, AUTO_INCREMENT, TABLE_ROWS, DATA_LENGTH
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
ORDER BY AUTO_INCREMENT DESC
LIMIT 20;

-- 2) 主键当前最大值（比 AUTO_INCREMENT 更准，尤其是刚删过数据）
SELECT MAX(id) AS max_id FROM t_order;

-- 3) 近 30 天的日增，用来算还能撑多少天
SELECT ROUND(COUNT(*) / 30) AS per_day
FROM t_order
WHERE created_at >= NOW() - INTERVAL 30 DAY;
```
余量 = 上限减 `MAX(id)`。可用天数 = 余量除以日增。落到行动上有三档：余量超过两年，记个水位告警就行；余量在半年以内，立项排期；已经到顶，先止血再迁移。

止血有个临时办法，把列改成无符号，上限直接翻一倍，`ALTER TABLE t_order MODIFY id INT UNSIGNED NOT NULL AUTO_INCREMENT`。代价还是重建表，只是重建完之后能多撑几年。它还有个前提：应用层得接得住这个值。Java 里 id 还是 int 的表，改完这里照样报错，只不过错从数据库挪到了应用。所以这招只适合"先把今晚过去"的场景，不能当长期方案。

```
-- 水位告警：按主键实际类型取上限，超过 70% 就报（BIGINT 不参与，比值永远接近 0）
SELECT c.TABLE_NAME,
       c.COLUMN_TYPE,
       t.AUTO_INCREMENT,
       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
         END * 100, 1) AS used_pct
FROM information_schema.TABLES t
JOIN information_schema.COLUMNS c
  ON c.TABLE_SCHEMA = t.TABLE_SCHEMA
 AND c.TABLE_NAME = t.TABLE_NAME
WHERE t.TABLE_SCHEMA = DATABASE()
  AND c.EXTRA LIKE '%auto_increment%'
  AND c.DATA_TYPE IN ('tinyint', 'smallint', 'mediumint', 'int')
HAVING used_pct > 70
ORDER BY used_pct DESC;
```
这里有个口径要留意。8.0 里 `information_schema.TABLES.AUTO_INCREMENT` 是缓存值，默认 24 小时刷新一次。要拿准数，跑之前 `ANALYZE TABLE`，或者在会话里 `SET information_schema_stats_expiry = 0`。不然你看到的余量，可能是昨天的。

## 四、改类型的真实代价

`MODIFY id BIGINT` 这句话写起来一行，执行起来是另一回事。改列类型连 `ALGORITHM=INPLACE` 都不支持，只能走 `ALGORITHM=COPY`。COPY 的意思是建一张同结构的新表，把数据一行行拷过去，拷完再替换。这段时间里，这张表的写入全部阻塞，所有二级索引跟着重建，磁盘还要留出接近一张表的空间。亿级的表，几个小时起步。

|方案|怎么做|代价|什么时候用|
|:-:|:-:|:-:|:-:|
|原生 `ALTER`|`ALGORITHM=COPY`，建新表、逐行拷、拷完替换|写入全程阻塞，IO 翻倍，所有二级索引重建，主从延迟拉长，尾部要拿 MDL|能接受停写，或者有足够长的维护窗口|
|gh-ost / pt-osc|建影子表，拷数据，追增量，最后切换|需要额外一份空间，切换瞬间仍有短暂锁，工具本身要调|大表的主流做法|
|新表双写|建新表，代码双写，回填历史，切读|工程量最大，但可控，随时能退|核心交易表，不敢赌窗口|

选哪条，看两件事：这张表能停多久，以及主从延迟能容忍多久。能接受停写两小时、从库追得上，原生 `ALTER` 最省事。一分钟都停不了，就走 gh-ost。已经在做架构改造，顺手一起做双写。

有个细节必须提前确认：这张表上有没有外键。MySQL 要求外键两侧的列类型完全一致，主表一改，约束会先把 DDL 拦下来，报外键不兼容。有外键的表，得先拆约束再改，改完重建。这个顺序搞反，DDL 会在第十分钟失败，然后回滚，白等一小时。

## 五、要跟着改的，不止这张表

我第一次帮人做这件事，只算了主库的重建时间，没算从库。第二天凌晨，从库回放这条 COPY DDL，SQL 线程卡在那里，延迟告警响了一路。后来整理了一份清单，每次动手前照着过一遍。

- 从库不用单独改，但要盯它回放这条 DDL 要多久、磁盘够不够，SQL 线程卡住得有人管

- 独立报表库、逻辑备份恢复出来的实例，不在同一条复制链路上，得单独改

- 异构同步链路的目标端、分片中间件的路由规则与分片键范围配置

- 有外键关联的子表，类型必须同步，否则约束先把 DDL 拦下来

- 应用层的实体、DTO、接口出入参，`int` 到 `long` 是硬改

- 缓存 key 的拼接方式、序列化格式，老数据里存的是 int

- 导出脚本、对账脚本、数据分析的落库表结构

这里面最容易被忘的是缓存和序列化。`id` 从 21 亿变成 30 亿，如果某处用了 32 位有符号序列化，读出来就是负数。而这种错不会在改表当天暴露，要等新号真正越界才出现，可能是一个月后。

## 六、预防：建表那一刻就定下来

新表一律 `BIGINT UNSIGNED`，没有例外。一行多四个字节，一亿行大约四百兆；每个二级索引的叶子还要再存一份主键，这个数得往上加。跟一场亿级重建比，这笔账不用算。

自增不要拿来做业务单号。它不连续，回滚和批量插入都会跳号；它可预测，看号的大小就能反推业务量；它还绑在单库上，多写节点只能靠步长硬凑。业务单号要的是唯一、可读、可追溯，自增只占一个单表内的唯一。

水位监控要提前建。上面那段 SQL 塞进巡检脚本，每月跑一次，把用量超过 70% 的表列出来。这条成本最低，收益最直接，我现在的库里固定有这么一项。

## 七、避坑清单

`AUTO_INCREMENT` 的当前值不能只看 `information_schema`，它是缓存值，删过数据的表要用 `MAX(id)` 复核。两个数差得远，说明有大量空洞，真实余量比看上去少。

双主、多写节点的库，余量要按步长折算。`auto_increment_increment=2` 就是打对折，这个数很容易被漏掉，建库时设的，几年后没人记得。

最后一条是我自己踩的。有次在测试环境复现号段耗尽，我把表清空，又把 `AUTO_INCREMENT` 改回 1，重新灌了一批数据。当时对上了，觉得验证成功。上线前我照同样的做法在生产演练了一次，两千多条订单的 `id` 和历史归档数据撞上了，对账直接差钱。从那以后我明白，自增号段是"一次性资源"，删掉的行不会把号还给你。演练也一样，宁可用新表造，也不要动生产表的计数器。

## 写在最后

自增耗尽不是容量问题，是类型选错了一次、几年后来收账。它的特点是可预测：上限固定，日增可测，余量能算。所以它属于少数"完全能提前发现"的故障。

这篇不讨论主键该选自增还是 UUID，那是建表时的选择。这里只讲已经选了 int、并且已经到顶之后，这笔账怎么结。号段能扩，类型不能，这是两件事。

真到了要改的那天，别急着写 `ALTER`。先数清楚有多少张表、多少个子表、多少处代码在用它。改表是半天的事，改全链路是两周的事。

那张表最后没走原生 `ALTER`，换了在线工具重建，切过去之后 `id` 接着往下走，业务没停。

你们库里最老的那张表，主键是什么类型？算过还能撑几年吗？把这个数发到评论区，我帮你核一遍预算。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋

去年帮一个团队看故障，订单表突然开始报主键冲突。开发说程序在重试，重试多了撞上重复键。我看了一眼表结构，id INT NOT NULL AUTO_INCREMENT，再看当前最大值，2147483647。这个数太有辨识度了，它就是 int 有符号的上限。那张表跑了七年，从零开始一格一格走到头，走到最后一天才开始报错。自增耗尽这件事最好玩的地方就在这：它在建表那天就注定了，只是账要七年后才结。

MySQL自增ID用尽怎么处理？21亿到顶后的改类型实战

一张跑了七年的订单表，某天开始报主键冲突，查到最后是自增号用到了 2147483647。文章算清各整数类型的上限与余量、到顶之后的三种表现、改列类型的 COPY 代价，并给出不止一张表要跟着改的清单和自增水位监控。

数据库

运维

后端

数据库自增主键耗尽如何提前发现与修复？详解MySQL整型上限、报错三种表现、余量计算SQL、INT改BIGINT的真实代价与ALTER方案，附建表避坑清单，助你避免主键冲突和号段复用陷阱。

数据分析

代码解释

中间件

路由

MySQL

Java

腾讯云数据库特惠，新用户首单0.5折起


腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL自增ID用尽怎么处理？21亿到顶后的改类型实战-腾讯云开发者社区-腾讯云

MySQL自增ID用尽怎么处理？21亿到顶后的改类型实战

MySQL自增ID用尽怎么处理？21亿到顶后的改类型实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐