RC隔离级别不能防止死锁，因其虽减少普通范围查询的间隙锁，但唯一索引冲突检测仍强制加S/X型记录锁；死锁主因是加锁顺序不一致、索引缺失及事务设计问题，与是否设置RC无关。
RC隔离级别不能防止死锁，它只是减少了部分间隙锁的使用范围；真正引发死锁的，是唯一索引冲突检测、加锁顺序不一致、索引缺失或事务设计问题——和你设没设READ COMMITTED无关。
RC下为什么INSERT ON DUPLICATE KEY UPDATE还会死锁
很多人以为设成RC就“没间隙锁”，于是死锁消失了，结果线上照样报Deadlock found when trying to get lock。根本原因在于：InnoDB对唯一索引（主键或UNIQUE二级索引）做重复值检查时，必须加S型或X型record-level锁，哪怕在RC下也绕不开。
- 两个事务并发执行
INSERT ... ON DUPLICATE KEY UPDATE，目标是同一组唯一键（比如songid = 16和songid = 17），但插入顺序相反 - 事务A先查
songid = 16，对其二级索引记录加S锁（用于冲突判断）；事务B同时查songid = 17，也加S锁 - 接着A尝试插入
songid = 17，需升级为X锁，但被B持有的S锁阻塞；B同理卡在songid = 16 - 此时
WAITING FOR THIS LOCK TO BE GRANTED里出现index songid_idx和lock_mode X locks rec but not gap，就是典型证据
为什么SHOW ENGINE INNODB STATUS里看到gap before rec
RC下确实禁用了普通范围查询的间隙锁，但官方文档明确写着：gap locking is used only for foreign-key constraint checking and duplicate-key checking。也就是说，“间隙”只保留在唯一键冲突校验路径上。
- 当你看到
lock_mode X locks gap before rec或insert intention lock，基本说明事务正试图往某个唯一索引间隙插入新值 - 例如已有
songid = 10和songid = 20，两个事务同时想插songid = 15，都会申请(10,20)这个间隙上的插入意向锁 - 如果其中一方已持有了该间隙内某条记录的X锁（比如因ON DUPLICATE触发），另一方就会等在
gap before rec上 - 别只盯着
PRIMARY索引——死锁常始于uk_column_key这类二级唯一索引，回表前就锁住了
配置了RC却没生效的常见原因
很多团队改完全局变量就以为万事大吉，结果SELECT @@transaction_isolation在业务SQL执行前一查，还是REPEATABLE-READ。
- MySQL服务端默认仍是
REPEATABLE-READ，连接池（如HikariCP）复用连接后，会继承服务端默认值 - ORM（如MyBatis）没在每次获取连接后显式执行
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - Spring
@Transactional(isolation = Isolation.READ_COMMITTED)在某些版本或代理模式下未透传到底层JDBC连接 - 验证是否真生效，必须在业务SQL执行前查
SELECT @@transaction_isolation，而不是只看@@global.transaction_isolation
真正决定死锁频率的，从来不是隔离级别开关本身，而是你的SQL是否走索引、事务是否包含RPC或文件IO、多点更新有没有统一顺序——RC只是把一部分锁“松开”了，但没松开的部分，反而更容易暴露设计缺陷。
