高并发SQL INSERT锁竞争成为系统瓶颈的原因
很多开发者想当然地认为INSERT只会锁定新插入的那一行，但实际情况远比这复杂。它不仅要施加行锁，还需要在检查唯一约束、分配自增ID以及维护二级索引时，额外申请insert intention lock、gap lock、next-key lock，甚至表级auto-inc lock。这些锁并非各自独立运作——举个典型场景：两个事务同时插入同一手机号，第一个获得X锁后，第二个只能等待，而这一等，就可能拖住整个事务提交链，形成连锁阻塞。
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缓冲区填满→刷盘延迟→提交更慢→锁持有更久。调参只能暂时缓解，必须从索引设计、唯一键选型、事务粒度三处同时切入才能根本解决。