自增ID冲突本质是AUTO_INCREMENT值未对齐已有数据最大ID，需查MAX(id)和当前AUTO_INCREMENT值并确保前者小于后者，再用ALTER TABLE重置为MAX(id)+1。
恢复时自增ID冲突，本质是目标表的 AUTO_INCREMENT 值没对齐已有数据的最大ID，不是数据本身不能导——重置它，问题就解了一大半。
恢复前必须查清两个关键值
导入或恢复 SQL 文件前，不查 MAX(id) 和当前 AUTO_INCREMENT 值，等于蒙眼开车。两者不一致，100% 触发 ERROR 1062: Duplicate entry for key 'PRIMARY'。
- 查当前最大主键：
SELECT MAX(id) FROM your_table;（注意：如果表为空，结果为NULL，需按空表逻辑处理） - 查当前自增值：
SHOW TABLE STATUS LIKE 'your_table';，看Auto_increment字段；或用SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='your_table'; - 如果
AUTO_INCREMENT≤MAX(id)，插入新记录必撞；如果远大于MAX(id)，虽不报错但会制造大片 ID 空洞
ALTER TABLE AUTO_INCREMENT = N 的安全写法
这个语句不是“设完就生效”，它只影响下一次无显式指定主键的插入行为，且仅对 InnoDB 表可靠（MyISAM 在重启后可能回退）。
- 设的
N必须严格大于MAX(id)，推荐设为MAX(id) + 1 - 执行前确保表无写入，否则可能被并发 INSERT 干扰（尤其大表）
- 示例：
ALTER TABLE orders AUTO_INCREMENT = 50001;（假设SELECT MAX(id) FROM orders返回50000） - 执行后立即验证：
SHOW CREATE TABLE orders;确认AUTO_INCREMENT=50001已写入
mysqldump 恢复时的坑与绕过方式
默认 mysqldump 会在导出文件末尾写入 ALTER TABLE ... AUTO_INCREMENT = X，但这个值来自备份时刻，恢复到已有数据的表时大概率失效。
- 不要依赖 dump 文件自带的
AUTO_INCREMENT设置——它只适合空表或全新库 - 导入前手动删掉 dump 文件里所有
ALTER TABLE ... AUTO_INCREMENT行（用sed -i '/AUTO_INCREMENT=/d' backup.sql） - 或者分两步走：先用
mysql -e "SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;"关约束，再导入，最后手动ALTER TABLE重置 - 更干净的做法：导出时加
--no-create-info，只导数据；结构单独导，导入后再统一重置自增
已报 ERROR 1062 时的紧急止血操作
如果已经执行导入并报错，别急着删数据或改 SQL，先定位冲突点再决策。
- 错误信息里明确写了冲突值，例如
Duplicate entry '1024' for key 'PRIMARY'，立刻查：SELECT * FROM your_table WHERE id = 1024; - 如果该记录是脏数据（比如测试残留、误导入），直接
DELETE FROM your_table WHERE id = 1024; - 如果该记录是合法业务数据，说明你导入的数据本就含重复 ID —— 此时不应重置
AUTO_INCREMENT，而应改用INSERT IGNORE或ON DUPLICATE KEY UPDATE导入 - 极端情况：ID 接近
INT上限（2147483647），重置已无意义，得考虑字段类型升级和迁移方案
真正容易被忽略的是：自增ID冲突从来不是孤立事件，它背后往往暴露了备份策略缺陷、迁移流程缺失校验、或开发环境随意 INSERT 显式ID的习惯。修复一次 AUTO_INCREMENT 很快，但让下次恢复不再踩坑，得从 dump 参数、导入脚本、以及团队操作规范上动刀。
