迁移后报 ERROR 1062 是因目标表 AUTO_INCREMENT 值未对齐已导入数据最大 id；需查 MAX(id) 和 AUTO_INCREMENT，若前者≥后者则必冲突，应设 ALTER TABLE ... AUTO_INCREMENT = MAX(id)+1 并验证。
迁移后立刻报 ERROR 1062，说明目标表的 AUTO_INCREMENT 值没对齐已导入数据的最大 id——不是数据导错了，是自增值卡在旧位置没动。
查清 MAX(id) 和 AUTO_INCREMENT 两个值
别猜，直接查。这两值不一致，下一条无显式 id 的 INSERT 必撞。
-
SELECT MAX(id) FROM your_table;—— 注意：空表返回NULL，需单独处理（如设为0） SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';- 如果
AUTO_INCREMENT ≤ MAX(id)，冲突已注定；如果远大于（比如MAX(id)=1005，AUTO_INCREMENT=50000），虽不报错但会浪费 ID 段，还可能提前触发INT溢出
ALTER TABLE AUTO_INCREMENT = N 怎么设才真正生效
这个语句只影响「下一次未指定主键的插入」，且仅对 InnoDB 表可靠。
-
N必须严格大于MAX(id)，推荐直接设为MAX(id) + 1（不是+0，也不是随便填个大数） - 执行前确保表无写入，否则并发
INSERT可能干扰判断 - 执行后立即验证：
SHOW CREATE TABLE your_table;确认AUTO_INCREMENT已更新 -
MyISAM表不适用——重启后可能回退，线上环境别用
mysqldump 导入时 AUTO_INCREMENT 没生效？别信导出文件末尾那行
默认 mysqldump 会在 SQL 文件末尾写 ALTER TABLE `t` AUTO_INCREMENT=12345;，但它只适合空表或全新库，迁移到已有数据的表时大概率失效。
- 导入时用了
--force参数？遇到前面语法错误就跳过后续所有语句，包括这行ALTER - 某些 ORM 或迁移脚本会自动过滤
ALTER类语句（防误操作），导致根本没执行 - 检查方法：打开导出文件，搜索
AUTO_INCREMENT=，确认存在且未被注释 - 更稳妥做法：导入前手动删掉 dump 文件里所有
AUTO_INCREMENT=行（sed -i '/AUTO_INCREMENT=/d' backup.sql），再统一执行校准
已经报错 ERROR 1062 了，怎么快速止血
别删数据、别改字段类型，先定位冲突点再决策。
- 看报错里的具体 ID：
Duplicate entry '1024' for key 'PRIMARY' - 立刻查：
SELECT * FROM your_table WHERE id = 1024;—— 确认该记录是脏数据还是合法数据 - 如果是误插的脏数据，可
DELETE或UPDATE掉 - 如果是合法数据，马上执行：
ALTER TABLE your_table AUTO_INCREMENT = 1025;（或更高，留一点缓冲）
最容易被忽略的点：增量迁移时，很多人只在全量阶段校准一次，之后就不管了。但每轮增量都可能插入新记录，MAX(id) 已变，AUTO_INCREMENT 却还卡在旧值——每次增量前，都得重查重设。
