InnoDB自增锁瓶颈源于INSERT ... SELECT等语句不适用innodb_autoinc_lock_mode=2，仍用语句级锁；需通过SHOW PROCESSLIST、慢日志、INNODB STATUS等确认，再以分页插入、禁用约束、排序主键等实操优化。
为什么innodb_autoinc_lock_mode=2开了还是卡住插入
因为这个参数只对INSERT INTO t VALUES ()类简单插入生效，而对INSERT INTO t SELECT、REPLACE INTO t SELECT、LOAD DATA INFILE等批量/混合插入，InnoDB 仍会退化为语句级 AUTO-INC 锁——执行多久，锁就 hold 多久。你看到大量线程卡在Waiting for table level lock或慢日志里INSERT ... SELECT耗时突增，不是参数没生效，是语句本身就不走轻量路径。
常见误判点：
- 误以为“开了 mode=2 就万事大吉”，结果线上全是
INSERT ... SELECT，锁争用照旧 - 混用显式 ID 和
NULL，比如INSERT INTO t VALUES (100,'a'), (NULL,'b')，触发内部重试和锁升级 - 没确认
binlog_format是否为ROW，盲目调参导致主从复制异常
怎么确认真是 AUTO-INC 锁在拖慢你
别靠猜。直接查三处关键信号：
-
SHOW PROCESSLIST里大量线程状态为Waiting for table level lock（注意：不是行锁） - 慢日志中
INSERT语句平均耗时陡增，且EXPLAIN显示执行计划正常（排除索引问题） -
SHOW ENGINE INNODB STATUS的TRANSACTIONS部分出现AUTO_INC字样等待链 - CPU 火焰图或
perf top能看到innodb_autoinc_lock相关函数持续高占比
如果以上至少两点命中，基本可锁定是自增锁瓶颈，而非磁盘 IO 或连接池满。
绕过锁瓶颈的实操写法优先级
参数调优见效慢、风险高；SQL 写法改一点，效果立竿见影。按推荐顺序落地：
- 把
INSERT INTO t SELECT ... FROM s WHERE ...拆成应用层分页 + 批量VALUES：每批 500–1000 行，主键值必须单调递增（否则二级索引分裂吃掉一半性能） - 用
INSERT ... ON DUPLICATE KEY UPDATE替代REPLACE INTO：前者只在真正插入新行时推进自增计数器，更省 ID、更少锁 - 大批量导入前临时关约束：
SET UNIQUE_CHECKS=0、SET FOREIGN_KEY_CHECKS=0，导入完再开并ANALYZE TABLE - 避免在事务中混杂
SELECT或其他 DML，防止锁范围意外扩大到无关行
批量提交 + 参数组合的硬性前提
这两项一起上才出真效果，但缺一不可：
-
SET autocommit = 0+ 显式START TRANSACTION/COMMIT，单个事务别塞超 5000 条（防锁升级） -
innodb_flush_log_at_trx_commit=0可再提速 30%，但断电会丢最近 1 秒事务——仅限离线导入场景 - 导入前
DROP INDEX非主键索引，导入完CREATE INDEX，比边插边更新索引快数倍 - ORM（如 MyBatis）默认会把批量语句自动拆成单条，得关掉
useServerPrepStmts=false和批量代理逻辑，直连 JDBC 执行原生 SQL
最易被忽略的一点：主键乱序插入（比如按时间戳倒序）会让所有优化归零——InnoDB 的 B+ 树分裂成本远高于锁竞争本身。数据必须提前按主键排序，这点在 ETL 脚本里常被跳过。
