迁移后报ERROR 1062，说明AUTO_INCREMENT未对齐MAX(id)；必须导入前校验二者，且ALTER TABLE AUTO_INCREMENT=N仅在N>MAX(id)时生效，推荐设为MAX(id)+1。
迁移后插入新数据立刻报 ERROR 1062，说明目标表的 AUTO_INCREMENT 值没对齐真实数据最大 ID —— 这不是偶发错误，而是迁移流程漏掉了关键校验步骤。
迁移前必须查清两个值：MAX(id) 和 AUTO_INCREMENT
很多人等导入完才发现冲突，其实只要在导入前跑两条语句就能预判：
– 查当前最大 ID：SELECT MAX(id) FROM your_table;
– 查表准备从哪开始分配新 ID：SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table';
如果返回的 AUTO_INCREMENT ≤ MAX(id)，下一条无显式 ID 的 INSERT 必然触发 ERROR 1062；如果远大于 MAX(id)（比如最大是 1005，AUTO_INCREMENT 却是 50000），虽不报错，但会浪费 ID 段，还可能提前触发 INT 溢出预警。
ALTER TABLE AUTO_INCREMENT = N 的生效条件和坑
这个语句只在「下一次 INSERT 不指定主键」时生效，且仅对 InnoDB 表可靠。执行前必须确认：
– N 必须严格大于 MAX(id)，推荐设为 MAX(id) + 1（不是 +0，也不是随便填个大数）
– MyISAM 表不适用，重启后可能重置
– 执行时会加表级写锁，大表务必选低峰期操作
– 它不会修改已有数据，只影响后续自动生成逻辑
示例：ALTER TABLE orders AUTO_INCREMENT = 100001;（前提是 SELECT MAX(id) FROM orders; 返回 100000）
mysqldump 导入时 AUTO_INCREMENT 没被还原？检查导出文件末尾
默认 mysqldump 会在导出 SQL 文件末尾写类似 ALTER TABLE `t` AUTO_INCREMENT=12345; 的语句，但以下情况会导致它被跳过：
– 导入时用了 --force 参数，遇到语法错误就忽略后续语句
– 导入脚本或工具自动过滤了 ALTER 类语句
– 使用了 --skip-auto-increment（不推荐）
解决方法：打开导出的 SQL 文件，直接搜索 AUTO_INCREMENT=，确认该行存在且未被注释；若缺失，手动补上并确保执行。
导入时已报 ERROR 1062，怎么快速恢复
别急着删数据或改字段类型，先定位冲突点：
– 看报错里的具体 ID，例如 Duplicate entry '1000' for key 'PRIMARY'
– 执行 SELECT * FROM your_table WHERE id = 1000; 确认该记录是否本就存在（是脏数据还是正常数据）
– 如果是误插的脏数据，可 DELETE 或 UPDATE 掉
– 如果是合法数据，立刻执行 ALTER TABLE your_table AUTO_INCREMENT = 1001;（或更高，留一点缓冲）
注意：此时表可能已被部分写入，务必先停写或确认无并发 INSERT，否则刚设好又被覆盖。
最常被忽略的点是：AUTO_INCREMENT 是表元数据，不是数据本身；它不随 INSERT SELECT 或程序迁移自动同步，必须显式校准。哪怕用 mysqldump，也要盯住导出文件末尾那行 ALTER 是否真被执行了。
