innodb_autoinc_lock_mode用于控制innodb自增列并发插入时的锁策略，非禁用持久化；mysql 8.0强制启用自增值持久化且不可关闭，该参数仅影响锁范围与持续时间，取值0/1/2分别对应表级锁、默认连续模式、无锁交错模式。
innodb_autoinc_lock_mode 不是用于“禁用”自增值持久化，而是控制自增列在并发插入时的锁行为；MySQL 8.0 默认启用且无法禁用自增变量的持久化——这是内核级行为变更，与该参数无关。
你看到的“默认禁用”印象，大概率源于混淆了两个独立机制：
- ✅ 自增值持久化（
AUTO_INCREMENT值重启不丢失）：MySQL 8.0 强制开启，无开关，不依赖配置项 - ❌
innodb_autoinc_lock_mode：仅影响插入时的加锁策略，和值是否落盘完全无关
innodb_autoinc_lock_mode 是什么，为什么它常被误读
这个参数决定 InnoDB 如何为批量或混合插入分配自增值，核心是平衡性能与语义确定性。它有三个取值：
-
0（传统模式）：所有 INSERT 都用表级AUTO_INC锁，串行化分配，保证语句级自增连续，但吞吐低 -
1（默认，交错模式）：简单 INSERT（单行、无子查询）用轻量互斥量，批量 INSERT（如INSERT ... SELECT）仍用表锁；大多数场景下性能好、语义可接受 -
2（无锁模式）：所有 INSERT 都不加AUTO_INC锁，完全并发，但可能导致主从复制中自增列不一致（ROW 格式下安全，STATEMENT 格式下危险）
注意：
innodb_autoinc_lock_mode=2在 MySQL 5.7+ 默认要求 binlog_format=ROW，否则会报错或降级警告。
MySQL 8.0 的自增值持久化到底怎么工作的
它不靠配置开关，而是由引擎层自动完成：
- 自增计数器的当前值写入 redo log，并在每次变更后刷盘
- 重启时，InnoDB 从 redo log 中恢复最后已提交的自增值，不是从
SELECT MAX(id)推算 - 对应系统表
mysql.innodb_autoinc是只读视图，不能手动修改，也不用于运行时计数
验证方式很简单：
CREATE TABLE t (id INT AUTO_INCREMENT PRIMARY KEY); INSERT INTO t VALUES (),(),(); DELETE FROM t WHERE id = 3; -- 此时 SHOW CREATE TABLE t 显示 AUTO_INCREMENT=4 -- 重启 MySQL 后再执行 SHOW CREATE TABLE t，仍是 AUTO_INCREMENT=4（8.0 行为） -- 而 5.7 会变成 AUTO_INCREMENT=3
容易踩的坑：调错参数以为能“关掉持久化”
- 试图通过
SET GLOBAL innodb_autoinc_lock_mode = 0来让自增值“变回 5.7 风格”？没用。持久化机制不受影响。 - 在主从架构中把
innodb_autoinc_lock_mode设为2却用 STATEMENT 复制？会导致从库自增错位甚至主键冲突。 - 认为
ALTER TABLE ... AUTO_INCREMENT = N会覆盖持久化值？它确实会写入数据字典并刷 redo，但只是显式重置，不是“关闭”机制。
真正影响持久化行为的，只有存储引擎类型（必须是 InnoDB）和 MySQL 版本（≤5.7 不支持，≥8.0 强制启用）。
自增持久化本身没有“开关”，它的复杂性藏在恢复路径和 redo 日志协同上——如果你在做备份恢复、主从切换或跨版本迁移，这才是真正需要盯住的地方。
