必须先确认AUTO_INCREMENT是否大于MAX(id)，否则下一次INSERT必报ERROR 1062；若≤则冲突，应设为MAX(id)+1并低峰期执行ALTER TABLE；远大于则为空洞型跳号，不影响写入但需警惕ID溢出。
查清当前最大ID和AUTO_INCREMENT值是否匹配
跳号本身不报错，但后续插入可能直接失败——关键先确认是不是“真异常”。执行两条命令：SELECT MAX(id) FROM your_table; 和 SHOW CREATE TABLE your_table;，重点看后者输出里 AUTO_INCREMENT=xxx 这个值。如果 AUTO_INCREMENT 小于或等于 MAX(id)，下一次 INSERT 必然触发 ERROR 1062 Duplicate entry；如果远大于 MAX(id)（比如表里只有100条数据，却显示 AUTO_INCREMENT=1000000），说明是迁移时没带自增值，属于“空洞型跳号”，不影响写入但可能干扰业务逻辑。
安全重置AUTO_INCREMENT值的实操要点
重置不是随便设个数，必须满足“大于当前最大ID”这个硬条件，否则MySQL会静默修正甚至引发冲突：
- 先锁表防并发写入：
FLUSH TABLES WITH READ LOCK;（生产环境务必在低峰期操作） - 查出最大ID后，执行：
ALTER TABLE your_table AUTO_INCREMENT = 12345;（12345 是MAX(id) + 1） - 注意：该语句只影响下一条自增插入，不会修改已有数据；如果表为空，
ALTER TABLE ... AUTO_INCREMENT = 1即可 - InnoDB 表即使删过数据，
AUTO_INCREMENT也可能卡在高位，必须手动重置，TRUNCATE TABLE虽能重置但会清空数据，慎用
迁移时避免自增异常的关键动作
下次导出导入，别依赖默认行为就完事，得盯住几个具体环节：
- 用
mysqldump导出时，**不要加--skip-auto-increment**，它会丢掉AUTO_INCREMENT注释；默认行为会保留类似ALTER TABLE `t` AUTO_INCREMENT=10001;的语句 - 导入后立刻检查SQL文件末尾是否有上述
ALTER TABLE语句，并确认它被执行（有些工具或脚本会跳过这类语句） - 若用程序迁移（如Python批量写入），要么显式指定
id字段，要么导入后补一句ALTER TABLE重置 - 主从环境迁移更要小心：从库执行
ALTER TABLE前，先停掉SQL线程，避免复制冲突
跳号已发生且插入失败怎么办
如果已经出现 ERROR 1062 Duplicate entry '12345' for key 'PRIMARY'，说明新ID被占了，不能硬设更小的值：
- 先查冲突ID是否存在：
SELECT * FROM your_table WHERE id = 12345; - 如果结果非空，且该记录是脏数据（比如测试残留），可
DELETE或UPDATE掉；否则必须把AUTO_INCREMENT设到一个安全值，比如MAX(id) + 100 - 极端情况如ID即将溢出
INT（接近21亿），别只调AUTO_INCREMENT，得同步升级字段类型：ALTER TABLE your_table MODIFY id BIGINT UNSIGNED AUTO_INCREMENT; - 别信“重启MySQL能修复”——5.7及之前版本重启反而会让
AUTO_INCREMENT回退到MAX(id)+1，8.0+虽持久化但跳号源头仍在运行时分配逻辑
真正麻烦的从来不是跳号本身，而是有人在没确认 MAX(id) 的情况下，直接执行 ALTER TABLE ... AUTO_INCREMENT = 1 或随意设个小值，结果一插入就撞上已有ID。修复动作永远要基于数据现状，而不是“我以为它该是多少”。
