MySQL在RR级别无法完全避免写入冲突，根本原因是Next-Key Lock仅在当前读中触发，且唯一索引等值查询不封锁间隙，导致并发事务均判断记录不存在而同时插入，引发唯一约束冲突或死锁。
MySQL在RR隔离级别下无法完全避免写入冲突，根本原因不是锁机制失效，而是Next-Key Lock只在当前读中触发、且对等值查询（尤其是唯一索引）不封锁间隙——这导致多个事务能同时“发现记录不存在”，继而并发插入，最终撞上唯一约束或陷入死锁。
SELECT ... FOR UPDATE 在唯一索引上不锁间隙
当WHERE条件命中唯一索引（如主键或UNIQUE列）的等值查询时，InnoDB只加记录锁（Record Lock），不加间隙锁（Gap Lock）。这意味着：即使SELECT ... FOR UPDATE WHERE id = 100返回空，它也只锁定id=100这个点（若存在），但不会封锁(99, 101)之间的间隙。
- 事务A执行
SELECT * FROM t WHERE uk_key = 'abc' FOR UPDATE，查无此行 → 成功加锁（实际是加了间隙锁？错，唯一索引等值查不到时，只锁supremum或infimum，不封实际间隙） - 事务B执行相同语句 → 同样成功，因为间隙锁在唯一等值场景下不生效（或仅锁伪记录）
- 两者都尝试
INSERT INTO t (uk_key) VALUES ('abc')→ 都申请插入意向锁（Insert Intention Lock），但该锁与对方已持有的间隙锁/伪记录锁冲突 → 死锁或唯一键冲突
INSERT ON DUPLICATE KEY UPDATE 不是原子防重方案
INSERT ... ON DUPLICATE KEY UPDATE看似能兜底，但它内部先走插入路径：若唯一键已存在，则回退并执行UPDATE；但“插入路径”仍会触发插入意向锁竞争，且在高并发下无法避免两个事务几乎同时判断“键不存在”。
- 它不提前声明“我要占住这个键范围”，只是事后纠错
- 若业务逻辑依赖“查无则插”的语义（比如分布式锁、幂等表），该语句无法替代显式加锁
- 在RR下，两次
SELECT ... FOR UPDATE之间插入的行，可能让第二次UPDATE影响意料之外的行数
混用快照读与当前读放大写入冲突风险
写入冲突常源于事务内先用快照读（SELECT）做判断，再用当前读（INSERT/UPDATE）执行——前者看不到新提交数据，后者却要和最新状态竞争。
- 事务A：
SELECT COUNT(*) FROM t WHERE status = 'pending'→ 得0 - 事务B：插入
status = 'pending'并提交 - 事务A：
INSERT INTO t (...) SELECT ... WHERE NOT EXISTS (...)→ 插入成功，但此时已存在同条件行 - 后续其他事务再查，就会看到“幻影”插入，且A的插入可能破坏业务唯一性假设
真正可控的写入冲突规避方式
靠隔离级别默认行为防冲突是脆弱的；必须主动控制锁粒度和读写模式。
- 所有涉及“先查后写”的逻辑，统一以
SELECT ... FOR UPDATE开头，且确保WHERE条件走有效索引（非唯一二级索引更易触发间隙锁） - 对唯一键场景，若需强排他，改用
SELECT ... FOR UPDATE配合范围条件（如WHERE uk_key >= 'abc' AND uk_key ），逼出间隙锁 - 避免在事务中穿插普通
SELECT和INSERT；要么全快照读（接受冲突可能性），要么全当前读（用锁兜底） - 在应用层做轻量级重试（捕获
Deadlock found when trying to get lock或Duplicate entry），比依赖RR“自动防护”更可靠
最易被忽略的一点：RR的间隙锁保护是“单向时间防御”——它只拦住加锁之后的插入，对加锁之前已存在的数据盲区无能为力。写入冲突往往就发生在那个毫秒级的时间缝隙里。
