SELECT ... FOR UPDATE在RR级别下会加间隙锁，根本原因是InnoDB默认使用Next-Key Lock（记录锁+间隙锁）防幻读；若查询值不存在，则锁定其应处的索引间隙，如id=5不存在且邻值为3和8，即锁(3,8)区间。
RR 隔离级别下 SELECT ... FOR UPDATE 会加间隙锁
可重复读（REPEATABLE READ）不是“完全不加间隙锁”，而是默认启用 Next-Key Lock（记录锁 + 间隙锁），这是 InnoDB 防幻读的核心机制。当你执行 SELECT ... WHERE col = ? FOR UPDATE，而该 col 值不存在时，InnoDB 不会什么都不锁，而是锁定该值“应处”的索引间隙（Gap Lock）。比如 id = 5 不存在，且索引中相邻记录是 (3, 8)，那就会在 (3, 8) 这个间隙上加锁。
关键点在于：间隙锁之间**不互斥**。两个事务可以同时在同一个间隙上成功加锁——这为死锁埋下伏笔。
两个事务并发插入同一间隙时触发死锁循环
典型场景是幂等插入：先查后插。事务 T1 和 T2 同时执行：
-
SELECT * FROM t_order WHERE order_no = 1007 FOR UPDATE→ 都在(1005, 1010)间隙加了 Gap Lock - T1 执行
INSERT INTO t_order (order_no, ...) VALUES (1007, ...)→ 需要申请插入意向锁（Insert Intention Lock），但被 T2 的间隙锁阻塞 - T2 同样执行
INSERT→ 插入意向锁被 T1 的间隙锁阻塞
此时形成“T1 等 T2 释放间隙锁，T2 等 T1 释放间隙锁”的闭环，MySQL 死锁检测器介入，回滚其中一个事务。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
READ COMMITTED 能避免，但代价是可能幻读
把隔离级别设为 READ COMMITTED 后，InnoDB 默认禁用间隙锁（除唯一索引的重复检查等极少数情况）。这意味着：
-
SELECT ... FOR UPDATE对不存在的记录**不加任何锁** - 两个事务都能跳过查询直接插入，但需靠应用层或唯一约束兜底防重复
- 如果业务允许“两次快照读看到不同结果”（即幻读），RC 是更轻量、更少死锁的选择
注意：READ COMMITTED 下唯一索引仍可能加间隙锁做重复校验，这不是 bug，是保证唯一性必需的行为。
不改隔离级别也能破局，但得动代码和索引
保留 RR 隔离级别时，避免这类死锁的关键是打破“查+插”流程对间隙锁的依赖：
- 用
INSERT ... ON DUPLICATE KEY UPDATE替代先查后插，让冲突由唯一索引约束捕获，不走间隙锁路径 - 确保查询条件走**唯一索引**（如主键或
UNIQUE字段）：这时SELECT ... FOR UPDATE只加 Record Lock，不会锁间隙 - 缩短事务生命周期：查完立刻插，中间不做耗时操作（如远程调用、复杂计算），减少锁持有时间
- 统一所有事务对多表/多行的访问顺序，避免循环等待链
最常被忽略的一点：开发者往往只盯着 SQL 是否加锁，却没检查 WHERE 条件是否真的命中了索引。全表扫描下，RR 会升级为表级锁或大量行锁，死锁概率反而更高。
