空表并发insert必死锁是因rr级别下next-key lock导致所有事务在(-∞,+∞)间隙争抢insert intention lock而形成循环等待；解决核心是绕过间隙锁，如用insert...on duplicate key、降级到rc隔离级别或预占位。
MySQL大并发插入死锁不是配置问题，而是间隙锁（Gap Lock）在RR隔离级别下的必然行为，尤其空表或低数据量时必现；解决核心是绕过或控制间隙锁冲突，而非调高超时或重试。
为什么空表并发INSERT必死锁？
MySQL InnoDB在REPEATABLE READ隔离级别下，默认使用Next-Key Lock（记录锁 + 间隙锁）。空表时，主键范围是(-∞, +∞)，所有并发INSERT都试图在同一个间隙加Insert Intention Lock——它虽兼容，但因锁排队机制，在无数据可锚定的情况下形成循环等待链。InnoDB检测到后回滚其中一个事务，报错：Deadlock found when trying to get lock; try restarting transaction。
典型现象：两条并发插入，一条成功（id=1），另一条死锁后重试成功（id=3），id=2跳号。
用INSERT ... ON DUPLICATE KEY避免SELECT FOR UPDATE的锁升级
很多业务用SELECT ... FOR UPDATE + INSERT做幂等插入，但若WHERE条件字段没走唯一索引（比如只建了普通索引），会升级为表锁或扩大间隙锁范围，极易死锁。直接改用INSERT ... ON DUPLICATE KEY UPDATE更安全：
- 要求字段必须有
UNIQUE KEY或PRIMARY KEY（如order_no设为唯一索引） - 不依赖应用层判断，原子执行：存在则忽略/更新，不存在则插入
- 只锁命中行及其间隙，不触发额外的
SELECT锁等待链 - 示例：
INSERT INTO orders (order_no, user_id) VALUES ('ORDER123', 1001) ON DUPLICATE KEY UPDATE user_id = VALUES(user_id);
降低隔离级别到READ COMMITTED可禁用间隙锁
在确认业务能接受“不可重复读”的前提下，把事务隔离级别设为READ COMMITTED，InnoDB会自动禁用间隙锁和Next-Key Lock，只保留记录锁：
- 执行
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;（会话级）或在my.cnf中全局配置transaction_isolation = 'READ-COMMITTED' - 此时
INSERT仅锁定实际插入的行，不再锁定间隙，空表并发插入不再死锁 - 代价：幻读可能重现，比如事务A查不到某订单，事务B插入后提交，事务A再查就看到了——若该场景不影响业务（如订单创建后不二次校验），可接受
插入前预占位：用REPLACE INTO或INSERT IGNORE减少竞争窗口
当无法改隔离级别、又不能加唯一约束时（如UUID主键+业务字段唯一），可用REPLACE INTO或INSERT IGNORE替代手动判断：
-
REPLACE INTO本质是DELETE + INSERT，会先尝试删除匹配行再插，需确保有唯一索引支撑匹配逻辑 -
INSERT IGNORE遇到唯一键冲突直接跳过，不报错，适合“只插不更新”场景 - 两者都比
SELECT FOR UPDATE+INSERT少一次网络往返和锁持有时间，缩短竞争窗口 - 注意：
REPLACE INTO会触发自增ID跳号，且影响AUTO_INCREMENT计数器
真正难处理的是那些既要求强一致性、又无法加唯一索引、还必须用RR隔离级别的场景——这时得靠应用层队列或分布式锁前置收敛请求，数据库层已无优雅解法。间隙锁不是bug，是InnoDB为保证可重复读付出的必要代价；与其对抗，不如重构插入路径让它“不争”。
