mysql主从自增id不连续的根源是主从各自独立维护内存中的auto_increment值，且binlog不复制已分配未使用的id；事务回滚、唯一键冲突、批量插入预分配等产生的“空洞”在切换后暴露，并非切换本身导致。
innodb_autoinc_lock_mode 不是主从切换后自增 ID 不连续的直接原因，真正起作用的是：主库和从库各自维护独立的自增值内存状态，且 binlog 复制不传递“已分配但未使用”的 ID。
主从切换本身不会“导致”不连续——它只是把一个原本就存在不连续现象的库推到了前台。你看到的“切换后突然不连续”，其实是旧主库积累的空洞（比如事务回滚、唯一键冲突、批量插入预分配等）在新主库上暴露了出来。
主从切换时，自增值为什么不同步？
MySQL 主从复制只同步 INSERT、UPDATE、DELETE 等逻辑日志（STATEMENT 或 ROW 格式），但不记录以下内容：
-
AUTO_INCREMENT计数器当前值（InnoDB 存在内存中，不进 binlog） - 被回滚事务预占的 ID
- 因
INSERT IGNORE或唯一键冲突失败而跳过的 ID - 批量插入（
INSERT ... SELECT、LOAD DATA）按innodb_autoinc_lock_mode预分配的 ID 段
所以从库启动时，会根据自身表中现有数据执行 SELECT MAX(id) + 1 来初始化自增值（MySQL 5.7 及之前）；MySQL 8.0 虽支持持久化，但仅限单实例重启场景，**不跨实例同步**。
innodb_autoinc_lock_mode=2 在主从环境下的实际影响
该模式（交错模式）允许并发 INSERT 不加表级 AUTO_INC 锁，性能高，但会加剧 ID 不连续——尤其在主库高并发写入时：
- 主库执行
INSERT INTO t VALUES (),(),();，可能一次性预分配 ID 段 [100–102] - 若其中某条因唯一键冲突失败，ID 101 被“浪费”，但 102 已计入计数器
- 这个过程不记 binlog，从库完全不知道 101 曾被跳过
- 切换后，新主库继续从 103 开始，但业务侧看到的是 100→102→103，中间缺了 101
注意：innodb_autoinc_lock_mode 参数本身**不参与复制**，主从可以设不同值（但强烈不建议），它的行为只影响本地 ID 分配节奏。
如何验证当前主从自增值差异？
不要只看 SHOW CREATE TABLE 输出的 AUTO_INCREMENT=N，它只是当前内存值的快照，且从库可能滞后。应组合检查：
- 查当前最大 ID：
SELECT MAX(id) FROM t; - 查内存计数器：
SELECT @@auto_increment_offset, @@auto_increment_increment;（辅助判断步长逻辑） - 查真实自增值（需 SUPER 权限）：
SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t'; - 对比主从结果是否一致——不一致就是空洞来源之一
特别注意：InnoDB 表的 AUTO_INCREMENT 值在 INFORMATION_SCHEMA 中可能延迟更新，最可靠方式仍是 SELECT MAX(id) + 1（前提是没手动插入过大 ID）。
切换后发现 ID 突然跳跃，还能补吗？
不能安全地“填空”。试图用 ALTER TABLE t AUTO_INCREMENT = N 把值调小，MySQL 会静默忽略（除非 N > 当前 MAX(id)）。强行重置风险极高：
- 如果应用或下游服务缓存了旧 ID（如分页游标、幂等 key），重置后可能重复写入
- 主从切换期间若还有写入未同步，
ALTER操作可能被复制到从库，引发主从自增值进一步错位 - GTID 模式下，在从库执行
ALTER TABLE会导致同步中断
真正需要关注的不是“不连续”，而是“是否唯一+是否超出范围”。只要 id 是 PRIMARY KEY 且类型足够（如 BIGINT UNSIGNED），空洞本身不影响索引、查询或性能。
