MySQL 8.0自增主键重启不重置，根本原因是计数器当前值被写入redo log并持久化；而5.7仅存于内存，重启时通过扫描B+树取max(id)+1重新初始化，导致手动设置的高值丢失。
MySQL 8.0 的自增主键重启不重置，根本原因是计数器写入了重做日志（redo log），而 5.7 仅存于内存；这不是“更可靠”的主观判断，而是设计上从易失到持久的硬性变更。
MySQL 5.7 自增计数器为什么重启就丢
5.7 的 AUTO_INCREMENT 计数器完全托管在 InnoDB 数据字典的内存结构中，不落盘。即使你手动执行 ALTER TABLE t AUTO_INCREMENT = 1000，这个值也只写进内存，不会同步到任何持久化介质。
常见错误现象：
- 插入 1~3 后删掉 id=3，再重启 MySQL，下一条插入的 id 又是 4（看似正常）——但若你曾用
INSERT INTO t(id) VALUES(999)强制跳过，重启后它会退回到max(id)+1，比如变成 4，导致后续插入冲突 - 主从复制中，从库重启后自增值落后主库，造成 INSERT … SELECT 或 REPLACE 冲突
本质原因：InnoDB 在启动时会扫描聚簇索引 B+ 树的最右叶子节点，取最大 id 值 +1 作为初始计数器，完全忽略之前内存里设过的高值。
MySQL 8.0 怎么做到重启不丢值
8.0 把自增计数器的当前最大值（not next value）作为元数据，随每次 INSERT 或显式 ALTER 操作，一起写入重做日志（redo log）。崩溃恢复时，InnoDB 会从 redo 中重放该记录，重建内存计数器。
关键行为差异：
- 首次建表时，
AUTO_INCREMENT = 1会被立即写入 redo；5.7 此时还不写 - 执行
INSERT INTO t VALUES()，8.0 在分配 id 后立刻记 redo；5.7 到事务提交才隐式更新内存计数器，且不落盘 - 即使表空，只要执行过
ALTER TABLE t AUTO_INCREMENT = 500，8.0 就会落盘；5.7 重启即失效
注意：SHOW CREATE TABLE 显示的 AUTO_INCREMENT 值在 8.0 中是可信的（来自数据字典持久化视图），而在 5.7 中只是内存快照，不可依赖。
容易被忽略的边界情况
持久化不是万能的，这几个点实际运维中常踩坑：
- 如果用
mysqldump --skip-auto-increment或导出时没带/*!80000 AUTO_INCREMENT=xxx */注释，导入到新实例仍按 5.7 方式初始化（从 max(id)+1 算） - 8.0 的持久化只覆盖「计数器当前值」，不保证全局单调——比如两个并发 INSERT 都拿到相同自增值（极罕见，需极端争用），此时仍靠唯一约束拦截，不是持久化能解决的
- 使用
innodb_autoinc_lock_mode = 0（传统锁模式）时，8.0 虽然持久化，但批量插入性能下降明显，且可能因锁等待导致计数器分配延迟
真正影响业务连续性的，从来不是“要不要持久化”，而是你是否清楚地知道：当前实例的自增值来源是内存扫描、还是 redo 恢复、还是 dump 文件里的注释——三者混用时，一致性就没了。
