空表或低数据量时并发insert必然死锁，是repeatable read下next-key lock在(-∞,+∞)间隙争抢insert intention lock导致的确定性循环等待；解决需绕过间隙锁，如用insert ignore、降级rc或预排序批量插入。
空表或低数据量时并发 INSERT 必然死锁，这不是重试、调大 innodb_lock_wait_timeout 或优化索引能绕开的——它是 REPEATABLE READ 隔离级别下 Next-Key Lock 的确定性行为。
为什么空表 INSERT 会触发 Insert Intention Lock 死锁
InnoDB 在 RR 级别对 INSERT 先申请 Insert Intention Lock（插入意向锁），它本身兼容，但必须在某个间隙（gap）上加。空表时主键范围是 (-∞, +∞)，所有事务都试图在同一个超大间隙加锁；没有锚定行，锁排队机制导致循环等待。InnoDB 检测后报错：Deadlock found when trying to get lock; try restarting transaction。
典型现象：两条并发插入，一条成功（id=1），另一条死锁后重试成功（id=3），id=2 跳号。
- 这不是“运气差”，而是只要满足「空表 + 并发
INSERT+ RR 隔离级别」就必现 -
SELECT FOR UPDATE后再INSERT会放大风险：若 WHERE 字段没走唯一索引，可能升级为全表间隙锁 - 用
SHOW ENGINE INNODB STATUS查TRANSACTIONS部分，重点关注lock_mode X locks gap before rec insert intention waiting
用 INSERT IGNORE 替代 ON DUPLICATE KEY UPDATE
当语义允许“冲突即丢弃”时，INSERT IGNORE 是更轻量、更低锁竞争的选择。它遇到唯一键冲突直接跳过，不加 X lock、不触发行更新、不维护二级索引变更日志；而 ON DUPLICATE KEY UPDATE 即使写成 id=id 这种伪更新，也会对目标行加 X lock，并可能引发索引分裂。
- 判断是否插入成功：用
ROW_COUNT()—— 返回1表示新增，0表示忽略 - 不要在关键路径上依赖
ON DUPLICATE KEY UPDATE做幂等控制，它本质是「查 + 锁 + 可能更新」三阶段操作 - 确保冲突字段有
UNIQUE KEY或PRIMARY KEY，否则INSERT IGNORE不生效
降级到 READ COMMITTED 隔离级别
在确认业务可接受“不可重复读”的前提下，把隔离级别设为 READ COMMITTED，InnoDB 会禁用间隙锁和 Next-Key Lock，只保留记录锁。此时 INSERT 仅锁定实际插入的行，不再锁定间隙，空表并发插入不再死锁。
- 会话级生效：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 全局配置（需重启或动态设置）：
transaction_isolation = 'READ-COMMITTED'写入my.cnf - 代价是幻读重现：事务 A 查询无某订单，事务 B 插入并提交后，A 再查就看到——若该场景不影响核心逻辑（如订单创建后不二次校验），可接受
- 注意：RC 下
UPDATE/DELETE仍可能加间隙锁（仅在唯一索引等效于等值查询时才不加），但INSERT确实彻底规避了间隙锁
批量 INSERT 必须严格升序 + 分批
InnoDB 的间隙锁机制决定了：只要一批 INSERT VALUES () 中的主键值乱序，就大概率触发交叉加锁。例如插入 (100, 'a')、(99, 'b')、(101, 'c')，事务 A 锁了 99–100 间隙，事务 B 锁了 100–101 间隙，互相等待。
- 应用层插入前必须
ORDER BY id ASC，不能依赖数据库排序（INSERT SELECT ORDER BY不影响间隙锁行为） - 单批不超过 500 行；超过则拆成多条语句，每条内部严格升序
- 禁用
UUID()或MD5()直接作主键；若必须用雪花 ID，生成后立刻在内存排序，再拼 SQL - 建表时确认
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY，且没额外加UNIQUE索引（二级唯一索引会引发双倍间隙锁）
最易被忽略的一点：死锁多数不是插同一行，而是多个二级索引导致加锁顺序不一致——比如一个事务先锁 uk_order_sn 再锁 uk_user_id，另一个反之，就形成环路。所以索引结构设计和 SQL 执行路径一致性，比单纯调参更重要。
