MySQL 5.7的AUTO_INCREMENT重启后“跳变”或“回退”是因为其值仅存于内存，未持久化；重启时InnoDB执行SELECT MAX(id)+1重建计数器，若表中最大ID变小（如删除末尾行），新值即回退，且事务回滚、冲突等均会预分配并消耗ID，导致空洞。
MySQL 5.7 的 AUTO_INCREMENT 值为什么重启后会“跳变”或“回退”？
因为它的自增值只存在内存里，没写进任何持久化介质。服务一重启，InnoDB 就得重新扫描表里 id 列的最大值，再加 1 作为新的 AUTO_INCREMENT 值。比如你插到 100 后删掉最后几行，再重启——只要表里现存最大 id 是 95，新值就从 96 开始，而不是 101。
这个行为在批量插入、事务回滚、唯一键冲突等场景下更明显：哪怕 INSERT 最终没成功，自增值也已提前分配并递增，且不会回退。所以空洞（gap）是常态，而重启后的“重算”会让空洞看起来更混乱。
- 典型现象：
SHOW CREATE TABLE t显示AUTO_INCREMENT=105，重启后变成101或更低 - MyISAM 表不受此影响——它把当前值存在表文件头里，重启不丢失
- 无法通过
ALTER TABLE ... AUTO_INCREMENT=N长期固化，下次重启仍可能被覆盖
MySQL 8.0 是怎么做到重启不丢 AUTO_INCREMENT 值的？
核心改动是把自增计数器的变更写进了 redo log。每次分配新值时，InnoDB 不仅更新内存计数器，还生成一条 MLOG_INIT_FILE_PAGE 类型的 redo 日志记录，确保该操作可恢复。
这意味着：即使服务异常崩溃，重启后 crash recovery 阶段会重放这条日志，把自增值准确恢复到崩溃前的状态。不再依赖“扫描全表找 max(id)”这种低效又不可靠的方式。
- 生效前提：必须是 InnoDB 表；MyISAM 仍沿用老机制
- 不需要额外配置，默认开启；
innodb_autoinc_lock_mode不影响持久化逻辑 - 注意：如果手动执行
ALTER TABLE t AUTO_INCREMENT=200，这个值也会被持久化，但仅限于显式设置后的首次分配
升级到 MySQL 8.0 后，为什么有些表的 AUTO_INCREMENT 还是“不连续”？
持久化解决的是“重启丢失”问题，不是“避免空洞”问题。空洞（gap）来自三类必然行为：事务回滚、唯一键冲突、批量预分配（尤其 INSERT ... SELECT 或 LOAD DATA）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
比如 innodb_autoinc_lock_mode=2（MySQL 8.0 默认）会让并发插入各自预取一段 ID，哪怕只用掉一个，剩下都作废。这不是 bug，是为并发性能做的取舍。
- 别指望
AUTO_INCREMENT提供连续编号——它只保证唯一、递增、高效 - 如果业务强依赖连续 ID（如对外展示、分页推算），应改用应用层 ID 生成或 UUID + 时间戳组合
-
SELECT MAX(id)永远不能替代AUTO_INCREMENT机制，高并发下会严重不准
如何验证当前实例的 AUTO_INCREMENT 是否真正持久化？
最直接的方法是模拟一次干净重启，并观察值是否变化。不要依赖 information_schema.TABLES 的快照，它可能滞后；要用 SHOW CREATE TABLE 对比前后。
也可以查系统变量确认版本和引擎：
SELECT VERSION(), @@innodb_autoinc_lock_mode, @@storage_engine;
再执行一次插入后立刻 KILL -9 mysqld 进程（Linux），重启后检查：
- MySQL 5.7：大概率回到
MAX(id)+1 - MySQL 8.0：保持原值（前提是没发生 crash recovery 失败等极端情况）
真正容易被忽略的是：即使 8.0 持久化了，如果你用了 TRUNCATE TABLE，它仍会重置计数器——因为这是 DDL，会重建表结构，和重启无关。
