RC下UPDATE只锁命中行且语句级释放，RR加next-key锁并事务级持锁至结束，根本区别在于锁类型与释放时机；RC无间隙锁、支持半一致性读，RR为防幻读强制锁扫描范围。
RC下UPDATE只锁命中的行，RR会锁扫描过的所有行
根本区别在于锁的释放时机和锁类型：RC在UPDATE语句执行完后，立刻释放未匹配行的锁；RR则对整个扫描范围加next-key lock并持锁到事务结束。
常见错误现象：Lock wait timeout exceeded在RR下高频出现，尤其当WHERE没走索引触发全表扫描时——RR实际锁住数万行，而RC只锁住最终SET修改的那几行。
- 验证方式：执行
UPDATE t SET x = 1 WHERE name = 'alice'后查information_schema.INNODB_TRX，trx_rows_locked值在RC下≈实际更新行数，在RR下可能高达扫描行总数 - 关键前提：必须确保
WHERE条件能命中索引。否则RC虽不加间隙锁，但全表扫描+逐行加record lock，仍慢且资源占用高
RC默认禁用间隙锁，RR强制使用next-key lock
间隙锁（gap lock）是RR为防止幻读引入的机制，它锁住的是“值之间的空隙”，比如WHERE id > 10在RR下会锁住(10, +∞)区间，导致插入id = 11被阻塞；RC完全不加这类锁，只锁已存在且满足条件的记录本身。
典型场景：电商库存扣减UPDATE stock SET count = count - 1 WHERE sku_id = 'xxx'
- 若
sku_id无索引：RR下全表扫描 → 每行加next-key lock→ 等效表级锁；RC下仅对匹配行加record lock，其余行可自由操作 - 即使有索引，RC也避免了相邻值插入被卡住的问题——比如
sku_id = 'xxy'在RR下可能因间隙锁被堵，RC里完全不受影响
半一致性读让RC跳过被锁但不满足条件的行
这是RC独有的优化：当UPDATE扫描到一行已被其他事务加X锁时，RC不会直接阻塞，而是先读取该行最新已提交版本
- 若该版本不满足
WHERE条件：直接跳过，不加锁，继续扫描 - 若该版本满足条件：才尝试加
X锁，等待对方释放 - RR无此机制，只要扫到的行（无论是否被锁、是否满足条件），都会加
next-key lock并阻塞等待
这意味着在age = 20这类无索引条件更新中，RC最终仅锁目标记录，而RR会锁全表——并发能力差距就在这里拉开。
RC锁在语句级释放，RR锁在事务级释放
RC下，每个DML语句执行完毕即释放其持有的非修改行锁；RR下，所有锁（包括间隙锁、next-key lock）都必须等到COMMIT或ROLLBACK才释放。
性能影响明显：长事务中带RPC调用或消息回调时，RR容易形成锁等待链，而RC天然规避了这点。
容易被忽略的一点是：RC的轻量性依赖于应用层不滥用长事务。如果ORM自动开启事务却忘记commit，RC虽不拖住undo log，但语句级锁释放逻辑仍要求开发者对SQL执行边界有清晰认知——锁少不等于不用管锁。
