迁移前必须执行两条语句判断自增ID安全性：SELECT MAX(id) FROM your_table 和 SELECT AUTO_INCREMENT FROM information_schema.TABLES；若后者≤前者则必冲突，应设为MAX(id)+1并避开高峰执行ALTER TABLE。
迁移前不校验 AUTO_INCREMENT 和 MAX(id) 的差值，导入后必报 ERROR 1062；连续性只是表象，真正要防的是冲突，而冲突只发生在 AUTO_INCREMENT ≤ MAX(id) 时。
怎么快速判断目标表自增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';—— 看 MySQL 下次准备从哪个数开始分配
如果第二条返回值 ≤ 第一条结果，下一条无显式 id 的 INSERT 就会撞上已有主键；如果远大于（比如最大是 1005，AUTO_INCREMENT 却是 50000），虽不报错，但浪费 ID 段、可能提前触发 INT 溢出预警。
ALTER TABLE AUTO_INCREMENT = N 怎么设才生效
这个语句不是“设了就管用”，它只影响下一次没指定主键的插入，且仅对 InnoDB 表可靠：
- N 必须严格 >
MAX(id)，推荐直接设为MAX(id) + 1（不是 +0，也不是随便填个大数） - 执行会加表级写锁，大表务必选低峰期；线上慎用，可搭配
pt-online-schema-change - 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;（或更高，留一点缓冲）
最易被忽略的是：主从切换前没同步所有节点的 MAX(id)，只查了本机；还有配置了 auto_increment_offset 却没配 auto_increment_increment，等于白设。
