最直接的信号是错误日志中出现“Duplicate entry 'X' for key 'PRIMARY'”。当自增ID达字段上限（如INT UNSIGNED的4294967295），InnoDB反复尝试插入该最大值，触发主键冲突报错ERROR 1062，而非越界错误；若报ERROR 1467，则更可能是元数据损坏或权限问题。
查错误日志里是不是出现 Duplicate entry 'X' for key 'PRIMARY'
这是最直接的信号。当自增ID达到字段上限（比如 INT UNSIGNED 到了 4294967295），InnoDB 不再递增，而是反复尝试用这个最大值插入，必然触发主键冲突。你看到的报错不是越界错误，而是典型的唯一键冲突：ERROR 1062 (23000): Duplicate entry '4294967295' for key 'PRIMARY'。
注意区分：如果报的是 ERROR 1467 (HY000): Failed to read auto-increment value from storage engine，那更可能是表元数据损坏或权限问题，不一定是耗尽。
- 检查最近失败的 INSERT 语句是否都卡在同一个 ID 值上（比如全卡在
4294967295或2147483647） - 用
SHOW CREATE TABLE table_name确认主键列的数据类型和是否UNSIGNED - 对比当前最大 ID 和理论最大值：比如
SELECT MAX(id) FROM table_name返回4294967295，而列是INT UNSIGNED，基本就坐实了
用 SHOW TABLE STATUS 看 Auto_increment 值是否停摆
SHOW TABLE STATUS LIKE 'table_name' 返回结果里的 Auto_increment 字段，就是 MySQL 下次准备分配的 ID。如果它长期卡在一个固定值（比如始终是 4294967295），且 MAX(id) 也等于它，说明计数器已“撞墙”，不再推进。
这个值在 MySQL 5.6+ 存于 .ibd 文件，在 8.0+ 还写入 redo log，所以重启不会重置——它反映的是真实耗尽状态，不是临时缓存错乱。
- 别信
SELECT LAST_INSERT_ID()，它只返回最近一次成功插入的 ID，对排查耗尽无意义 - 如果
Auto_increment显示为NULL，说明表没设自增，或者引擎不是 InnoDB/MyISAM - 该值必须严格大于当前
MAX(id)；若显示值 ≤MAX(id)，MySQL 实际会自动修正为MAX(id)+1—— 但耗尽时它连这个修正都做不到
确认有没有人在手动调 ALTER TABLE ... AUTO_INCREMENT = N
有人看到空洞多，会手贱执行 ALTER TABLE t AUTO_INCREMENT = 1。这操作本身不报错，但 MySQL 会静默忽略——只要 N 小于等于当前最大 ID，它就当没听见。更糟的是，如果误设成一个已有记录的 ID（比如表里已有 id=100，却设成 AUTO_INCREMENT = 50），下一次插入就会直接撞上 ERROR 1062，看起来像“突然耗尽”，其实是人为埋雷。
- 查 binlog 或审计日志，确认近期有没有执行过这类
ALTER语句 -
SHOW VARIABLES LIKE 'auto_increment_%'可看全局步长和偏移，但单表耗尽主要看列定义，不是这些变量 - 主从架构下，如果主库
auto_increment_offset=1、从库设为2，长期双写会导致 ID 交错跳变，加速逼近上限——但这不会直接导致“卡死”，只是让耗尽来得更快
别被 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 欺骗
这两种写法会让语句不报错，但**完全不影响自增 ID 的预分配行为**。哪怕每条 INSERT 都因冲突被忽略，Auto_increment 值照常往上跳。你看到日志里“没报错”，但表的自增值可能已悄悄冲到顶——等真正需要插入新行时，才猝不及防崩掉。
用 SHOW WARNINGS 能看到被忽略的冲突（Level: Warning, Code: 1062），但它不告诉你 ID 跳了多少。真要盯住消耗速度，得定期比对 SHOW TABLE STATUS 里的 Auto_increment 值变化量。
- 监控脚本里别只抓 ERROR 日志，要定时采样
Auto_increment并告警：比如 24 小时内增长 - 业务层如果依赖“插入后返回 ID”做后续逻辑，
INSERT IGNORE导致返回 0 或旧 ID，可能引发下游数据错乱，比直接报错更危险
真正棘手的点在于：耗尽不是渐进式预警，而是临界点瞬间失能；且一旦发生，所有依赖该表写入的路径都会阻塞。最易被忽略的是——你以为在用 BIGINT，但建表时漏写了 UNSIGNED，实际只用了有符号上限（9223372036854775807 → 实际只剩一半）。
