迁移后自增id不连续是mysql innodb的预期行为，并非错误，主因是未继承源库空洞历史及innodb_autoinc_lock_mode=1预分配机制导致id段式跳跃。
迁移后自增ID不连续不是配置错了，也不是数据坏了，而是MySQL（尤其是InnoDB）在迁移过程中没继承源库的“空洞历史”，同时目标库按自己的规则重新分配ID——这本身是预期行为，无需修复。
迁移时AUTO_INCREMENT值没被正确恢复
mysqldump默认会在导出SQL末尾写类似ALTER TABLE `t` AUTO_INCREMENT=10001;的语句，但这个语句是否生效，取决于导入时的执行顺序和权限：
- 如果导入脚本被拆分、跳过注释行，或用程序批量执行INSERT而忽略DDL语句，
AUTO_INCREMENT值就不会被设置 - 即使语句被执行，InnoDB也只接受大于当前
MAX(id)的值；设小了会静默忽略（MySQL 8.0+会发warning，但不报错） - 用
INSERT SELECT或LOAD DATA INFILE迁移时，ID由目标库全新生成，源库的“跳号”记录不会被导出，自然不连续
innodb_autoinc_lock_mode=1 是迁移后空洞变大的主因
这是MySQL 5.7+默认值，它让批量插入（如INSERT INTO t SELECT ...）一次性预分配一段ID，而不是逐行分配。迁移常用这种模式，导致ID段式跳跃：
-
innodb_autoinc_lock_mode=1：语句级锁，预分配，空洞中等、并发好，适合大多数迁移场景 -
innodb_autoinc_lock_mode=2：无锁，最高并发，但同一语句内多个线程可能交错分配ID，空洞最不可控，且要求binlog为ROW格式 -
innodb_autoinc_lock_mode=0：全表AUTO_INC锁，严格连续，但迁移时会严重拖慢速度，线上基本不用
查当前值：SELECT @@innodb_autoinc_lock_mode;；改配置需重启或动态执行SET GLOBAL innodb_autoinc_lock_mode = 1;（注意主从一致性）
迁移后如何安全重置起始ID
重置不是为了“填洞”，只是为了防止下一条插入撞上已有ID（比如AUTO_INCREMENT值小于MAX(id)），引发ERROR 1062：
- 先确认现状：
SELECT MAX(id) FROM your_table;和SHOW CREATE TABLE your_table;（看AUTO_INCREMENT=xxx） - 若
AUTO_INCREMENT ，必须重置，否则必冲突；执行<code>ALTER TABLE your_table AUTO_INCREMENT = 12345;（12345 = MAX(id)+1） - 该操作不修改现有数据，只影响下一次
INSERT；务必在低峰期加READ LOCK或停写，避免并发插入干扰 - 别在从库执行此操作，GTID复制下会导致主从自增值错位，同步中断
真正危险的是“以为能修好”
人工重排ID（比如导出再导入、用变量重赋值、触发器补号）看似解决了“不连续”，实则埋下三颗雷：
- 外键约束断裂：除非提前
SET FOREIGN_KEY_CHECKS=0并同步更新所有关联表 - 主从复制异常：GTID事务ID冲突、ROW格式binlog解析失败
- 应用层失效：缓存、日志、前端分页逻辑里硬编码了旧ID，重排后查不到数据
空洞不影响索引、查询性能或唯一性保障；唯一需要警惕的，是业务代码里写了WHERE id BETWEEN ? AND ?或把ID当序号展示——这些地方才该改，而不是动自增机制本身。
