innodb_autoinc_lock_mode=2仅关闭简单insert的auto_inc表锁，不关闭insert select、replace select及混合模式插入的语句级表锁，且要求binlog_format=row、不依赖id连续性、避免混用on duplicate key update。
innodb_autoinc_lock_mode=2 能关掉哪些锁？
它不是“全关”，而是按语句类型区别对待：
— INSERT INTO t VALUES () 类简单插入不加 AUTO_INC 表锁，性能提升明显
— INSERT INTO t SELECT 或 REPLACE INTO t SELECT 仍退化为语句级表锁，改了参数也没用
— 混合模式（mixed-mode）如 INSERT INTO t (id, name) VALUES (1001, 'a'), (NULL, 'b') 同样不受益，预分配机制失效
— ID 必然出现空洞：事务回滚后已预分配的 ID 不回收，比如刚插完 1001，下一条可能是 1057
启用 mode=2 的三个硬性前提
跳过任一检查，上线即风险：
— 执行 SELECT @@binlog_format，结果必须是 ROW；如果不是，需在配置文件中设 binlog_format = ROW 并重启 MySQL
— 业务不能依赖 ID 连续性：不用 ID 做分页推算、不对外暴露 ID 当单号、没有代码写死 id + 1 就是下一条
— 避免混用 INSERT ON DUPLICATE KEY UPDATE + 显式指定自增字段（如 INSERT INTO t (id, name) VALUES (NULL, 'x') ON DUPLICATE KEY UPDATE ...），mode=2 下可能触发内部重试，反而更慢
不改参数也能绕开自增锁瓶颈的实操写法
参数只是辅助，真正压垮并发的是写入模式本身：
— 把大 INSERT SELECT 拆成应用层分页 + 批量多值 INSERT，例如每次 500–1000 行：INSERT INTO t VALUES (),(),()
— 用 INSERT ON DUPLICATE KEY UPDATE 替代 REPLACE INTO，前者只在真正插入新行时才推进自增计数器
— 确保主键字段类型足够大（如 BIGINT UNSIGNED），避免空洞加速耗尽 ID 范围
— 监控空洞程度：SELECT MAX(id) FROM t 与当前 Auto_increment 值对比
为什么调了 innodb_autoinc_lock_mode 还卡在 INSERT SELECT？
因为这类语句根本不受 mode=2 保护：
— SHOW PROCESSLIST 里大量线程状态是 Waiting for table level lock
— 慢日志中 INSERT INTO t SELECT 耗时突增，尤其搭配 REPLACE INTO t SELECT 或 LOAD DATA
— SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 部分出现 AUTO_INC 相关等待
— QPS 上不去，但 CPU 和磁盘 IO 并不高——说明瓶颈不在计算或存储，而在锁分配环节
— 这时候再调 innodb_buffer_pool_instances 或 innodb_log_file_size 都是白忙，得先动写法
