mysql自增锁瓶颈源于innodb_autoinc_lock_mode=1下高并发时mutex争用及insert select等语句强制持表级auto_inc锁；mode=2需binlog_format=row且不解决bulk/mixed插入锁问题，调参前须通过show engine innodb status确认waiting for auto-inc lock。
因为InnoDB在分配自增值时必须保证全局唯一，而默认的innodb_autoinc_lock_mode = 1用轻量mutex保护全局计数器——高并发下这个mutex本身就成了串行瓶颈；更关键的是，只要语句里带SELECT、REPLACE或显隐ID混用，InnoDB就强制升级为语句级表锁，锁住整张表直到执行完。
为什么SHOW PROCESSLIST里一堆Waiting for table level lock却查不到阻塞源
这不是行锁或间隙锁的问题，是自增锁（LOCK_AUTO_INC）在捣鬼。它不显示在普通锁视图里，但会出现在SHOW ENGINE INNODB STATUS的TRANSACTIONS部分，关键词是waiting for auto-inc lock。常见诱因包括：
-
INSERT INTO t SELECT * FROM s类语句：InnoDB必须预估行数并锁住一段ID范围，期间所有其他INSERT都被拦在外面 - 事务中混用显式ID和
NULL，例如INSERT INTO t VALUES (100, 'x'), (NULL, 'y')，触发mixed-mode逻辑，退化为语句级锁 - 应用层频繁执行单行
INSERT INTO t VALUES ()，QPS超3000后mutex争用导致CPU空转在innodb_autoinc_lock函数上
innodb_autoinc_lock_mode = 2为什么开了还是卡
Mode=2确实能跳过简单插入的锁，但它只对INSERT INTO t VALUES ()这类语句生效。以下情况它完全不管：
-
INSERT INTO t SELECT、REPLACE INTO t SELECT、LOAD DATA INFILE：仍走bulk insert路径，强制语句级锁 - 混合模式插入（mixed-mode）：哪怕只有一行用了
NULL，整条语句就降级 -
binlog_format不是ROW：设了mode=2但SELECT @@binlog_format返回STATEMENT，MySQL会静默拒绝生效，主从可能丢数据
还有一个容易被忽略的点：SET GLOBAL innodb_autoinc_lock_mode = 2只影响新连接，老连接继续用旧值——线上服务里一半连着旧配置，一半连着新配置，问题反而更难定位。
怎么确认真是auto-inc锁在卡，而不是别的问题
别急着改配置，先看三组信号是否同时出现：
-
SHOW PROCESSLIST里大量线程状态是Waiting for table level lock，但SHOW OPEN TABLES WHERE In_use > 0没发现异常表 - 慢日志里
INSERT耗时突增（比如从5ms跳到800ms），且语句含SELECT或REPLACE，但EXPLAIN FORMAT=JSON显示执行计划正常 -
SHOW ENGINE INNODB STATUS的TRANSACTIONS段落里出现*** (1) WAITING FOR THIS LOCK TO BE GRANTED: AUTO_INC t
如果这三项都命中，基本可以确定是自增锁瓶颈。这时候调参只是止痛，真正要动的是SQL写法——比如把INSERT INTO t SELECT拆成应用层分页+批量VALUES，或者用INSERT ON DUPLICATE KEY UPDATE替代REPLACE。
最常被忽略的一点：自增ID跳号不是bug，是设计必然。事务回滚、唯一键冲突、批量预分配都会消耗ID。如果你的业务逻辑依赖ID连续（比如用ID做分页推算或硬编码“ID+1”），再怎么调锁也没用——得换方案，比如UUID或雪花算法生成ID，彻底绕过MySQL的自增机制。
