迁移前应先执行SELECT MAX(id) FROM your_table和SELECT AUTO_INCREMENT FROM information_schema.TABLES确认目标表自增值是否大于最大ID，若≤则必冲突；ALTER TABLE AUTO_INCREMENT = MAX(id)+1可修复，但需在低峰期操作且仅对InnoDB可靠。
迁移前怎么查清当前AUTO_INCREMENT值是否安全
别等导入完报 ERROR 1062 才反应过来——先确认目标表的自增值和实际数据最大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
如果返回的 AUTO_INCREMENT ≤ MAX(id)，下一次 INSERT 必然冲突；如果远大于 MAX(id)，虽不报错但会留空洞（比如最大是 1005，AUTO_INCREMENT 却是 50000），后续插入可能浪费ID段或触发INT溢出预警。
ALTER TABLE AUTO_INCREMENT = N 的实操要点
这个语句看着简单，但线上踩坑最多：设了值却没生效、锁表太久、设错数字导致二次冲突。
- 必须确保
N > MAX(id)，且推荐设为MAX(id) + 1（不是 +0，也不是随便填个大数） - 只对
InnoDB表可靠；MyISAM表重启后可能重置，不建议在线上用 - 执行时会加表级写锁，大表慎操作——优先选低峰期，或搭配
pt-online-schema-change工具 - 该语句不会修改已有数据，只影响下一条无显式
id的INSERT
示例：ALTER TABLE orders AUTO_INCREMENT = 100001;（前提是 SELECT MAX(id) FROM orders; 返回 100000）
主从复制环境下用 auto_increment_offset 和 auto_increment_increment
这不是迁移“单次动作”的解法，而是预防多源写入长期冲突的配置级手段，适用于分库、双主、或需要人工补数据的场景。
原理很简单：让不同实例生成不重叠的ID序列。例如两台主库都设：
auto_increment_increment = 2- 主库A设
auto_increment_offset = 1→ 生成 1,3,5,7… - 主库B设
auto_increment_offset = 2→ 生成 2,4,6,8…
注意：offset 必须小于 increment，且所有参与节点的 increment 值必须一致；GTID 模式下仍建议配，因数据合并或故障切换时它仍是兜底防线。
mysqldump 导入时为什么AUTO_INCREMENT没被还原
默认 mysqldump 会在导出文件末尾写类似 ALTER TABLE `t` AUTO_INCREMENT=12345; 的语句，但很多人导入时用了 --force 或跳过错误，导致这行被忽略。
- 检查导出SQL文件末尾是否有
AUTO_INCREMENT=字样；没有？说明导出时加了--skip-auto-increment（不该加） - 导入时别用
mysql -f（--force），否则遇到警告就跳过，那行关键ALTER就丢了 - 更稳妥的做法：导入前手动执行
ALTER TABLE ... AUTO_INCREMENT = N;，而不是依赖dump文件自带语句
真正容易被忽略的是：即使导出文件里有那行 ALTER，如果目标表已存在且非空，MySQL 默认不会覆盖原 AUTO_INCREMENT 值——它只在 CREATE TABLE 时生效。所以迁移后必须主动查、主动设。
