MySQL 8.0+自增主键重启不回溯，因其将已分配的最大AUTO_INCREMENT值实时写入redo log，崩溃恢复时重放日志重建计数器；SHOW CREATE TABLE显示值可信，因该值源自持久化数据字典，与恢复逻辑一致。
MySQL 8.0 的自增主键重启后不回溯，不是靠“记住上次值”这种模糊逻辑，而是把每次成功分配的 AUTO_INCREMENT 值作为元数据写进 redo log，崩溃恢复时重放日志重建计数器——只要版本 ≥ 8.0.3、引擎是 InnoDB，这个机制就默认生效，无需配置。
为什么 SHOW CREATE TABLE 显示的 AUTO_INCREMENT 值可信
SHOW CREATE TABLE t 输出中的 AUTO_INCREMENT=xxx 是从 InnoDB 数据字典内存结构直读的，而该结构在 8.0+ 中由 redo log 持久化保障，与重启后实际使用的值一致。它不是缓存快照，也不是统计估算。
- 5.7 及以前：这个值纯内存维护，
mysqld进程一停就丢，重启后靠SELECT MAX(id) + 1重建，必然回溯 - 8.0+：只要发生过一次插入或
ALTER TABLE t AUTO_INCREMENT = N（且 N > 当前最大 id），该值就已落盘；即使删光数据、清空表，重启后仍延续 - 注意：
information_schema.TABLES.AUTO_INCREMENT不实时刷新，可能滞后几分钟，不能用于判断当前生效值
哪些操作会绕过持久化机制导致“看似回溯”
持久化本身很稳，但人为干预容易制造假象。所谓“回溯”，90% 是误读或误操作的结果：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
ALTER TABLE t AUTO_INCREMENT = N时设的 N 小于当前表中最大id（比如表里已有id=500却设成100）→ MySQL 不报错，但下条INSERT直接触发ERROR 1062 - 显式插入
INSERT INTO t(id, ...) VALUES (1, ...)→ 跳过自增逻辑，后续仍按原计数器走，造成空洞+隐性冲突风险 - 升级前是 5.7 表，且曾执行过
ALTER TABLE t AUTO_INCREMENT = 1→ 8.0 启动时加载的就是这个旧值，不会自动对齐MAX(id)+1 -
persisted_globals_load=OFF虽不影响自增值，但说明mysqld-auto.cnf机制失效，环境配置可能不可靠
如何验证当前表是否真正启用持久化
别只看版本号，要实打实查三件事：
- 查版本：
SELECT @@version;—— 必须 ≥8.0.3（8.0.0–8.0.2 是实验性支持，不稳定） - 查引擎：
SHOW CREATE TABLE t;—— 确认ENGINE=InnoDB；MyISAM表完全不走这套逻辑 - 查真实值：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t';—— 这个值和崩溃恢复逻辑一致，比SHOW CREATE TABLE更权威（尤其在高并发未 checkpoint 时）
真正容易被忽略的是：持久化解决的是“生存周期”问题，不是“连续性”问题。ID 空洞依然存在（事务回滚、唯一键冲突、显式插入都会消耗 ID），但只要没手动乱设 AUTO_INCREMENT，重启后就不会倒退——这点必须和业务方对齐认知，避免拿“不连续”当“故障”去排查。
