innodb_autoinc_lock_mode影响并发插入性能是因为其不同取值决定自增ID分配时的锁粒度：0全语句锁表、1默认兼容但批量操作仍锁表、2无锁预分配但ID不连续且需ROW格式binlog。
为什么innodb_autoinc_lock_mode会影响并发插入性能
MySQL 的自增主键在高并发 INSERT 场景下容易成为瓶颈，本质是 InnoDB 对自增值分配过程加锁导致的。默认值 1（“连续”模式）会在语句级加表级 AUTO_INC 锁，哪怕只是插入单行，也会阻塞其他插入操作。这在批量导入、消息队列消费写入等场景尤为明显——你看到的现象可能是：QPS 上不去、show processlist 里一堆 Waiting for table level lock、慢日志中大量 insert 耗时突增。
三种取值的实际行为和适用场景
innodb_autoinc_lock_mode 只能设为 0、1 或 2，不是越大越好，也不是越小越安全：
-
0（传统模式）：所有INSERT都用语句级AUTO_INC锁，保证自增值绝对连续，但并发最差；仅在需要 binlog statement 格式 + 主从强一致且不允许空洞的极老架构中才考虑 -
1（默认，连续模式）：普通INSERT（如INSERT INTO t VALUES ()）不锁表，但INSERT ... SELECT、REPLACE ... SELECT、LOAD DATA等批量语句仍会加锁；适用于大多数业务，兼容性好 -
2（交错模式）：所有INSERT都不加AUTO_INC锁，由预分配机制生成自增 ID，性能最高，但自增值可能不连续（如事务回滚后 ID 不回收），且要求 binlog 必须为ROW格式
调整前必须确认的三件事
直接改参数可能引发主从不一致或应用异常，务必检查：
- 确认
binlog_format是ROW：执行SELECT @@binlog_format，如果不是，需先在配置文件中设置binlog_format = ROW并重启 MySQL；STATEMENT模式下设为2会导致从库复制失败 - 确认业务不依赖自增 ID 的“连续性”：比如用 ID 做分页、做外部系统编号映射、或有硬编码假设“ID+1 就是下一条”的逻辑；一旦设为
2，事务回滚、批量插入部分失败都会留下空洞 - 确认没有使用
INSERT ... ON DUPLICATE KEY UPDATE+ 自增字段做唯一判断的写法：这种组合在mode=2下可能因预分配冲突触发重试，反而增加开销
线上调整的安全操作步骤
不要直接 SET GLOBAL —— 这只影响新连接，已有连接仍用旧值，且重启后失效。正确做法是：
- 编辑 MySQL 配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]段落下添加：innodb_autoinc_lock_mode = 2
- 确认所有从库配置同步修改（如果存在主从）
- 安排低峰期滚动重启：先从从库开始，再主库；避免主库重启期间从库追不上 binlog
- 重启后验证：
SELECT @@innodb_autoinc_lock_mode，并观察监控中Innodb_row_lock_waits和写入延迟是否下降
真正麻烦的不是参数本身，而是它暴露了应用对 ID 连续性的隐式依赖——这类假设往往藏在日志解析脚本、离线报表 SQL、甚至前端 URL 拼接里，改之前得先翻代码。
