MySQL 8.0.3+ InnoDB表自增主键默认持久化，重启后不回退至MAX(id)+1；需确认版本≥8.0.3、引擎为InnoDB，且避免ALTER TABLE设小值或显式插入冲突ID等误操作。

MySQL 8.0 中自增列（AUTO_INCREMENT）默认就是持久化的，**无需额外设置**——只要用的是 InnoDB 引擎、没手动干预、且版本 ≥ 8.0.3，重启后 AUTO_INCREMENT 值就不会回退到 MAX(id)+1。 但“默认开启”不等于“永远可靠”，很多问题出在误操作、环境配置或认知偏差上。下面直击实操关键点。

确认当前版本和引擎是否真支持持久化

不是所有 8.0 都等效：8.0.0–8.0.2 是实验性支持，8.0.3 起才稳定落地；MyISAM 表哪怕在 8.0 环境下也完全不走持久化路径。

• 查版本：SELECT @@version; —— 必须 ≥ 8.0.3
• 查引擎：SHOW CREATE TABLE t; —— 确认 ENGINE=InnoDB
• 查当前值来源：SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t'; —— 这个值和重启后恢复逻辑一致，比 SHOW CREATE TABLE 更准

为什么 SHOW CREATE TABLE 显示的 AUTO_INCREMENT 值看起来“没更新”？

SHOW CREATE TABLE 输出的 AUTO_INCREMENT=xxx 是内存缓存快照，可能滞后于 redo log 中最新已分配值。尤其在高并发插入后还没触发 checkpoint 时，它会“慢半拍”。

• 刚插入 id=10000 → SHOW CREATE TABLE 显示 AUTO_INCREMENT=10001 ✔️ 正常
• 接着 DELETE FROM t WHERE id = 10000 → SHOW CREATE TABLE 仍显示 10001 ✔️ 删除不改计数器
• 此时重启 → 恢复值仍是 10001，不会倒退 ✔️ 和 5.7 本质区别
• 但若你看到它卡在 10001 长时间不动，可能是并发写入未触发检查点，不是持久化失效

哪些操作会破坏持久化效果？

持久化机制本身很稳，但人为干预极易绕过它，导致“看着持久、实际断裂”。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• ALTER TABLE t AUTO_INCREMENT = N 在 8.0 中是持久化的，但如果你设的 N 小于当前表中最大 id（比如表里已有 id=5000 却设成 100），MySQL 不报错，但下次插入直接主键冲突
• 用 INSERT INTO t(id, ...) VALUES (1, ...) 显式指定小 ID，会跳过自增逻辑，后续仍按原计数器走，造成空洞+隐性风险
• 如果 persisted_globals_load=OFF（查 SHOW VARIABLES LIKE 'persisted_globals_load';），那整个 mysqld-auto.cnf 机制都失效——虽然不影响自增值，但说明环境配置可能不可靠

生产环境最该盯住的两个检查点

真正出问题的往往不是机制失效，而是“你以为它持久，其实你动过它，又忘了”。

• 每次执行 ALTER TABLE ... AUTO_INCREMENT = ... 前，必须先跑：SELECT MAX(id) FROM t; —— 否则无法预判是否埋雷
• 定期巡检：SELECT TABLE_NAME, AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND ENGINE='InnoDB' AND AUTO_INCREMENT > 1; —— 看哪些表的自增值远超当前数据量，提示可能存在历史大 ID 插入或手动调整

复杂点不在“怎么开”，而在“谁动过、动得对不对、有没有残留影响”。MySQL 8.0 的自增持久化是自动生效的底层能力，但它不替你校验业务逻辑，也不阻止你亲手填坑。