为什么MySQL的自增锁（Auto-inc Lock）会引起插入吞吐量瓶颈？-mysql教程-PHP中文网

bulk insert 类语句（如 insert select）在 mysql 5.7 默认模式下触发表级 auto-inc 锁，阻塞所有其他插入；mode=2 可规避但需严格满足 row+gtid 复制条件，否则丢数据或主从不一致。

为什么mysql的自增锁（auto-inc lock）会引起插入吞吐量瓶颈？

bulk insert 触发表级 AUTO-INC 锁，阻塞所有其他插入

真正卡住吞吐量的不是单行 INSERT VALUES，而是 INSERT INTO t SELECT ...、REPLACE INTO t SELECT ... 或 LOAD DATA 这类语句。MySQL 5.7 默认 innodb_autoinc_lock_mode = 1，对这类批量插入会预估行数后直接申请整段 ID，并持有一个表级 AUTO-INC 锁——直到整个语句执行完才释放，而非事务结束。

这意味着：哪怕子查询只返回 10 行，它也会锁住 t 表的自增机制；此时任何其他连接发起的 INSERT（哪怕是单行）都得排队等待，SHOW PROCESSLIST 里会出现大量 Waiting for auto-inc lock 状态。

并发多个 INSERT SELECT 时，它们按顺序排队，形成“锁队列”，实际是串行化执行
REPLACE INTO ... SELECT 和 INSERT ... ON DUPLICATE KEY UPDATE 在有唯一索引冲突路径下，也可能退化为 bulk 行为，触发同样锁
即使你把批量任务改成小事务提交，只要语句本身属于 bulk 类型，锁粒度就不会降级

innodb_autoinc_lock_mode=2 不是万能解，开错会丢数据

设成 innodb_autoinc_lock_mode = 2 确实能让所有插入都走轻量 mutex 分配，彻底避开表级锁，但前提是主从复制必须安全——否则 ID 冲突会导致从库报错 ERROR 1062 或复制中断。

必须同时满足：binlog_format = ROW + enforce_gtid_consistency = ON + gtid_mode = ON。缺一不可。只改 innodb_autoinc_lock_mode 而不检查 binlog 格式，SELECT @@binlog_format 返回 STATEMENT 的话，mode=2 就是危险操作。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

应用若依赖 ID 连续性做分页（如 WHERE id BETWEEN 1000 AND 1010），mode=2 下跳号会让查询漏数据
事务回滚后，已分配的 ID 不回收，空洞变多，可能影响某些基于 ID 范围的归档逻辑
MySQL 8.0 支持 mode=2 安全启用，但 5.7 中即使满足 ROW 格式，sync_binlog != 1 时仍存在极小概率主从不一致

simple insert 也未必安全：mixed-mode 插入会悄悄升级锁

看起来是单条语句，比如 INSERT INTO t (id, name) VALUES (1, 'a'), (NULL, 'b')，但它属于 mixed-mode insert——部分显式指定 ID、部分留 NULL 让 InnoDB 分配。这种写法在 innodb_autoinc_lock_mode = 1 下会被当作 bulk 处理，同样触发表级 AUTO-INC 锁。

更隐蔽的是 INSERT ... ON DUPLICATE KEY UPDATE：语法像 simple insert，但执行时若检测到唯一键冲突，内部会走 replace 路径，InnoDB 可能临时升为 bulk 模式加锁，尤其当表上有多个唯一索引时。

检查执行计划没用，得看 SHOW ENGINE INNODB STATUS 里的 auto-inc lock 等待记录
用 EXPLAIN FORMAT=TRADITIONAL 看不出锁行为，必须结合监控状态变量 Innodb_autoinc_readiness_wait（8.0+）或 INFORMATION_SCHEMA.INNODB_METRICS（5.7）
最稳妥的写法是避免 mixed-mode：要么全显式指定 ID，要么全留 NULL，不要混用

升级 MySQL 8.0 后不调参，性能可能更差

MySQL 8.0 的改进不是“去掉锁”，而是把 bulk 插入的锁拆成小段预分配（默认每批 64 个 ID），并让 AUTO-INC 锁和元数据锁（MDL）解耦。但这些优化默认不生效——你得手动设 innodb_autoinc_lock_mode = 2（且满足 GTID 条件），或至少把大 INSERT SELECT 拆成带 LIMIT 的循环批次。

如果只是升级版本却沿用 5.7 的配置，遇到高并发 bulk 插入时，8.0 反而可能因新锁调度逻辑暴露更多争用点，SHOW PROFILE FOR QUERY 里 auto-inc 阶段耗时反而升高。

8.0 新增 Innodb_autoinc_readiness_wait 状态变量，可直接查是否真被自增锁拖慢：SELECT * FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME = 'autoinc_readiness_wait';
不要迷信“升级就变快”，重点是确认 innodb_autoinc_lock_mode 是否匹配你的 binlog 设置和业务逻辑
真正难调的不是参数，而是混合了 bulk 和 simple 插入的 OLTP+OLAP 共存场景——这时拆语句比调参数更有效