MySQL自动递增主键重启后出现空洞或重置并非故障，而是由版本（5.7及更早vs 8.0+）和存储引擎（InnoDB vs MyISAM）决定：5.7及之前InnoDB重启时基于MAX(id)+1重建内存计数器，MyISAM始终依赖文件头；8.0+ InnoDB默认持久化自增值到数据字典，但MyISAM或异常配置下仍可能回退；事务回滚、唯一键冲突、显式插入等均会制造不可回收的空洞；手动ALTER TABLE修改AUTO_INCREMENT值若未严格大于当前MAX(id)，将导致后续插入报错1062，隐患隐蔽且难排查。
MySQL自动递增主键在重启后出现空洞或重置，不是故障，而是由引擎实现机制和版本差异决定的——关键看你是5.7还是8.0+，以及用的是InnoDB还是MyISAM。
MySQL 5.7及更早版本：重启必重算AUTO_INCREMENT
InnoDB的自增计数器只存在内存里，重启时会执行SELECT MAX(id) + 1 FROM t FOR UPDATE重建值。这意味着：
- 如果表中最大
id是100，但曾插入过200又删掉，重启后计数器变成101，而非201 -
SHOW CREATE TABLE里显示的AUTO_INCREMENT=xxx只是当前内存值，重启即失效 - 哪怕你手动执行过
ALTER TABLE t AUTO_INCREMENT = 500，只要没超过当时MAX(id)，重启后照样被覆盖 - MyISAM表即使在8.0环境下也走这套逻辑，因为它把最大ID存文件头，不依赖内存重建
MySQL 8.0+：默认持久化，但有例外
8.0起InnoDB将自增值变更写入redo log，并在checkpoint时落盘到数据字典，重启后恢复的是最后已提交的值。验证方式：
- 运行
SELECT @@version;确认≥8.0.30 -
SHOW CREATE TABLE t;输出中的AUTO_INCREMENT=xxx就是持久化值，重启不变 - 手动调大
ALTER TABLE t AUTO_INCREMENT = N会被真正持久化（前提是N >MAX(id)） - 注意：MyISAM表、或未启用innodb_redo_log_encrypt等异常配置下，仍可能退回到老行为
事务回滚和唯一键冲突也会“制造”空洞，且与重启无关
空洞不只来自重启——任何INSERT失败都会消耗ID：
-
INSERT INTO t VALUES (NULL, ...)执行前就预分配自增值，回滚或ERROR 1062都不退还 -
INSERT IGNORE、REPLACE INTO、INSERT ... ON DUPLICATE KEY UPDATE同样触发预分配 - 批量导入时若含重复值，每条冲突都吃一个ID，空洞肉眼可见
- 显式插入
INSERT INTO t(id, ...) VALUES (100, ...)会让后续ID从101起，中间所有值永久废弃
真正危险的不是空洞本身，而是人为干预后的隐性不一致
比重启回退更难排查的是DBA或开发手动执行ALTER TABLE t AUTO_INCREMENT = 500，而表里已有id=1000的记录。MySQL不报错，但下次插入直接ERROR 1062。这种问题不会在重启时暴露，而是在某次正常INSERT时突然炸出来。
所以生产环境任何对AUTO_INCREMENT的修改，必须先查SELECT MAX(id) FROM t;，确保目标值严格大于它——否则等于埋雷。
