空表并发insert必死锁，因rr级别下所有事务在(-∞,+∞)间隙争抢insert intention lock形成循环等待；解决需绕过间隙锁，如用insert on duplicate key update（单唯一键）、降级rc或预占位。
空表并发INSERT为什么会死锁
空表时InnoDB主键索引只有一个超大间隙(-∞, +∞)，所有并发INSERT都得在这个范围申请Insert Intention Lock。而这个意向锁和Gap Lock互斥——哪怕只插一行，事务A和B也会互相等待对方释放间隙锁，直接形成死锁环。
现象是：两条INSERT INTO t(name) VALUES ('a')并发执行，一个成功、一个报Deadlock found when trying to get lock; try restarting transaction；重试后自增ID跳号（比如插出1和3），说明中间那个自增值被回滚丢弃了。
关键点：SHOW ENGINE INNODB STATUS\G里能看到双方都在等PRIMARY上的X GAP锁。这不是SQL写错，是RR隔离级别下Next-Key Lock机制的必然行为。
INSERT ON DUPLICATE KEY UPDATE为什么也踩坑
它表面原子，底层仍走完整唯一约束检查流程。只要存在多个唯一索引（比如UNIQUE(email)和UNIQUE(phone)），并发插入冲突值时，两个事务可能分别持有不同唯一索引的S锁，又互相申请对方的X锁，瞬间卡死。
错误写法示例：INSERT INTO user (email, phone, name) VALUES ('a@b', '123', 'x') ON DUPLICATE KEY UPDATE name = VALUES(name)
- 风险点：email和phone都是
UNIQUE，InnoDB加锁顺序不保证一致 - 更隐蔽的是：即使只用主键，只要显式指定非自增主键值（如
INSERT INTO t(id, name) VALUES (100, 'a')），也会触发gap锁检查
SELECT FOR UPDATE怎么避免变成死锁源头
SELECT ... FOR UPDATE在RR下默认加Next-Key Lock，锁住记录+前后间隙。它本身不坏，坏在加锁顺序不统一。
必须强制按主键升序加锁：SELECT * FROM t WHERE status = 'pending' ORDER BY id ASC FOR UPDATE，否则不同事务扫描起点不同，锁顺序就乱了。
还要注意：
- 避免混合使用：同一事务里别先
SELECT FOR UPDATE走status索引，再UPDATE走id主键——锁范围和顺序都不可控 - 能不用就不用：纯校验逻辑改用
SELECT ... LOCK IN SHARE MODE或应用层重试，比硬加排他锁安全得多
真正有效的规避手段有哪些
死锁不是靠“重试”解决的，而是靠控制锁粒度、锁顺序和锁范围。重点不在“怎么扛”，而在“怎么绕”。
可行方案包括：
- 降隔离级别：把事务设为
READ COMMITTED，FOR UPDATE只锁匹配行，不锁间隙——前提是业务能接受RC语义（比如允许不可重复读） - 预占位：提前插入占位行（如
INSERT IGNORE INTO t(id) VALUES (1), (2), ...），缩小后续INSERT的间隙范围 - 用
INSERT ... ON DUPLICATE KEY UPDATE但只依赖单一唯一键（最好是主键），并确保WHERE条件总命中该索引最左前缀 - 秒杀类场景优先走主键精确更新：
UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty >= 1，彻底避开范围锁
最容易被忽略的一点：间隙锁死锁往往不发生在“慢SQL”上，而藏在看似无害的空表初始化、状态轮询、或批量导入前的清空重建环节里——这些地方一旦并发起来，(-∞, +∞)就是最危险的锁域。
