为何高并发执行SQL INSERT时锁竞争会成为系统瓶颈

INSERT不仅加行锁，还会根据唯一约束、自增ID分配和二级索引维护申请insert intention lock、gap lock、next-key lock甚至表级auto-inc lock；默认innodb_autoinc_lock_mode=1在批量插入时持表级自增锁至语句结束，导致并发串行化。

INSERT不是“只加行锁”那么简单

很多人默认INSERT只锁新插入的那行，其实它在检查唯一约束、分配自增ID、维护二级索引时，会申请多种锁：insert intention lock、gap lock、next-key lock，甚至表级auto-inc lock。这些锁不是孤立存在的——比如两个事务同时INSERT相同手机号，第一个拿到X锁后，第二个必须等它释放，而这个等待会卡住整个事务提交链。

唯一键冲突是隐形锁队列发生器

当高频写入撞上低基数唯一索引（如status、type、tenant_id），所有INSERT都会争抢同一段索引间隙。这不是“谁快谁赢”，而是形成FIFO锁等待队列：INSERT ... ON DUPLICATE KEY UPDATE尤其危险，它先查再试插再更新，全程持有目标记录的X锁+insert intention锁，后续请求全被堵死。

• 监控手段：查performance_schema.data_lock_waits能直接看到谁在等哪条记录
• 避免方式：别用状态位做UNIQUE字段；改用INSERT IGNORE或业务层控制重试间隔
• 区分度验证：用SELECT COUNT(DISTINCT field) / COUNT(*) FROM table看选择性，低于0.1就该警惕

自增锁模式不当会让并发插入串行化

MySQL默认innodb_autoinc_lock_mode=1（连续模式）在批量INSERT或含子查询的语句中，会持表级自增锁直到语句结束——哪怕只是INSERT INTO t SELECT ...，也会让后续所有INSERT排队。这不是事务级别锁，不随COMMIT释放，是真正的“语句级阻塞点”。

• 安全切换条件：binlog_format=ROW且确认业务接受非连续ID
• 生效命令：SET GLOBAL innodb_autoinc_lock_mode = 2，但需SUPER权限，重启失效
• 验证方式：SELECT @@innodb_autoinc_lock_mode, @@binlog_format

长事务和未走索引的UPDATE/DELETE会放大INSERT阻塞面

一个没提交的SELECT ... FOR UPDATE或WHERE条件没命中索引的UPDATE，可能已对整段索引区间加了gap lock。这时哪怕你INSERT的是全新主键值，只要落在那个gap里，就会被拦住——因为InnoDB要保证幻读隔离。这种阻塞不显山露水，但监控里能看到大量Lock wait timeout exceeded错误。

• 排查重点：检查慢查询日志里长时间未提交的事务，尤其是带FOR UPDATE或无WHERE的DML
• 索引验证：对所有写操作执行EXPLAIN，确保type字段不是ALL或index
• 隔离级别权衡：若业务可接受不可重复读，把transaction_isolation设为READ-COMMITTED，能去掉大部分gap lock

真正卡住INSERT的，往往不是磁盘IO或网络，而是锁等待引发的日志堆积与事务延迟之间的负向循环——等锁→事务变长→redo log缓冲区填满→刷盘延迟→提交更慢→锁持有更久。调参只是止痛，得从索引设计、唯一键选型、事务粒度三处同时切口。