mysql 5.7及以前版本重启后跳号是常态，根本原因是auto_increment值仅存于内存，未持久化；重启时innodb执行select max(id)+1重建计数器，导致其回退至当前最大id+1，而非原分配位置。
MySQL 5.7 及以前版本重启后跳号是常态，不是故障
根本原因是自增值只存在内存里，没写入磁盘。实例一重启，InnoDB 就会执行 SELECT MAX(id) + 1 来重建计数器——而这个值取决于当前表中**实际存在的最大 id**，不是上次分配到哪儿了。
比如你插入了 id=1～10，又删掉 id=9 和 10，此时表里最大 id 是 8；如果这时重启，AUTO_INCREMENT 就会被重置为 9，而不是原来的 11。看似“回退”，实则是从残留数据推导出来的新起点。
- 该行为在 MySQL 5.7 及更早版本中默认生效，且无法关闭
-
SHOW CREATE TABLE显示的AUTO_INCREMENT=xxx值，在重启后完全不可信 - 即使没删数据，只要事务预分配过但未提交（如 INSERT SELECT 中断），那部分 ID 也永远丢失，重启后不会补上
MySQL 8.0+ 已持久化自增值，但跳号仍可能发生
8.0 开始，InnoDB 把当前自增值记在 redo log 和数据字典表里，崩溃恢复后能准确还原。但这只解决“重启丢值”问题，不解决“分配即占用”逻辑。
真正导致跳号的源头仍在运行时行为：事务回滚、批量插入预分配、手动指定 ID 等操作，都会让计数器向前推进却不归还。持久化只是让这个“已推进的值”不再因重启而丢失。
- 查当前模式：
SELECT @@innodb_autoinc_lock_mode，mode=1（默认）下 INSERT SELECT 仍会预分配一大段 - 看当前分配点：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t_name' - 注意：
AUTO_INCREMENT值永远是“下一个待用值”，不代表前面全被占满；中间空缺无法自动填充
别试图靠 ALTER TABLE ... AUTO_INCREMENT = N 强行“修复”
这条语句只能设一个**大于当前表中最大 id 的值**，MySQL 会自动校验并向上取整。设小了会静默修正，设大了就真跳了——而且并发插入可能立刻撞上新设值，引发主键冲突。
- 执行前必须确认：
SELECT MAX(id) FROM t，然后设为MAX(id) + 1或更大 - 设完不等于立即生效：只有下一次真正需要自增时才用这个值；已有缓存或预分配段不受影响
- 高并发写入期间执行该语句，可能被其他会话的预分配行为覆盖，结果不可预测
真正要盯住的是 binlog 格式与 lock_mode 的组合
跳号本身无害，但若搭配错误配置，会引发主从不一致——这才是线上事故的高发区。
- 如果
binlog_format = STATEMENT，innodb_autoinc_lock_mode绝不能设为 2；否则从库重放时 ID 分配顺序不同，数据错位 - mode=2 要求 ROW 格式，且必须确保所有写入都走标准 INSERT，不能混用 LOAD DATA 或 REPLACE INTO
- 验证一致性：主库执行
INSERT INTO t VALUES (),();，立刻查从库是否拿到相同 id 序列
