MySQL 8.0 的AUTO_INCREMENT值为什么重启后不丢因为 InnoDB 把当前自增计数器的值不是“下一个值”而是已分配过的最大值作为元数据随每次INSERT或显式ALTER TABLE ... AUTO_INCREMENT N操作一并写入redo log。崩溃或正常重启时InnoDB 会从redo log中重放这条记录重建内存中的计数器。这和 5.7 完全不同5.7 的计数器纯内存维护重启时执行SELECT MAX(ai_col) FROM table_name FOR UPDATE扫描 B 树来推导初始值——它根本不知道你曾手动设过AUTO_INCREMENT 999更不会保留事务回滚后“已预分配但未提交”的 ID。SHOW CREATE TABLE输出的AUTO_INCREMENT值在 8.0 是可信的来自持久化数据字典5.7 只是内存快照随时可能失效即使表为空只要执行过ALTER TABLE t AUTO_INCREMENT 5008.0 就立刻落盘5.7 重启即归零首次建表时8.0 会立即把AUTO_INCREMENT 1写入redo log5.7 此时不写直到第一次插入才隐式更新内存哪些场景下 5.7 的自增丢失会导致真实故障不是“理论上可能出错”而是线上高频踩坑点用自增 ID 作业务主键比如订单号、用户 ID且依赖“单调递增不重复”语义重启后分配到已归档/删除的旧 ID引发唯一键冲突ERROR 1062 (23000): Duplicate entry X for key PRIMARY主从复制中从库重启后AUTO_INCREMENT回退与主库不一致导致INSERT ... SELECT、REPLACE INTO或 binlog 回放失败使用Xtrabackup备份恢复后ibdata1中的数据 ID 已到 6038085但新插入却从 6038081 开始——因为备份时没捕获内存中的计数器恢复后靠扫描取 max1 初始化归档老数据后清空表再手动ALTER TABLE ... AUTO_INCREMENT 1000000跳过历史段5.7 重启就变回max(id)1大概率撞上残留数据或下游系统缓存innodb_autoinc_lock_mode和持久化是两回事别混很多人以为调高innodb_autoinc_lock_mode比如设为 2能缓解自增问题其实它只控制并发插入时的锁行为影响性能和分配顺序完全不影响重启是否丢值。持久化与否只取决于 MySQL 版本和 InnoDB 是否把计数器写进redo log。也就是说即使innodb_autoinc_lock_mode 0传统锁模式8.0 仍不丢值即使innodb_autoinc_lock_mode 2交错模式5.7 重启照样丢持久化解决的是“生存周期”问题锁模式解决的是“并发竞争”问题迁移前必须验证的三个细节升级到 8.0 后不能默认“自动就安全了”。以下三点容易被忽略确认表引擎确实是InnoDBMyISAM表的AUTO_INCREMENT在 8.0 也不持久它走的是另一套逻辑检查是否启用了innodb_redo_log_capacity过小或innodb_flush_log_at_trx_commit 0虽然计数器写入redo log是强制的但极端配置下日志刷盘延迟可能影响崩溃恢复的完整性注意mysql.innodb_autoinc系统表的存在它在 8.0.30 才正式引入并用于辅助持久化早期 8.0.x如 8.0.20仅靠redo log 检查点需确认实际版本行为最隐蔽的问题往往出在混合环境主库 8.0、从库 5.7或者应用层缓存了SHOW CREATE TABLE里的AUTO_INCREMENT值并做本地判断——这些地方不会报错但会在某个凌晨重启后悄悄开始主键冲突。