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
