RC隔离级别下UPDATE必然加行级排他锁（X锁），这是保障读已提交和防止更新丢失的强制机制；锁类型取决于索引使用情况：命中主键/唯一索引则加Record Lock，无索引则全表扫描并逐行加X锁，即使无匹配记录也可能因唯一约束检查而加Gap Lock。
RC隔离级别下UPDATE必然加行锁，这是InnoDB实现“读已提交”的基础机制，不是可选行为。
UPDATE在RC下为什么必须加X行锁
RC要求事务只能看到其他事务已提交的数据，同时要保证写操作不被并发覆盖。UPDATE属于“当前读”，必须对目标记录加排他锁（X锁），否则两个事务同时更新同一行，后提交者会覆盖前者的修改，导致更新丢失——这直接违反ACID中的“I”（隔离性）。
即使WHERE条件没命中任何行，只要走索引定位，InnoDB仍会尝试加锁：查到索引位置但无记录时，只加Gap Lock（见下一点）；查到记录则加Record Lock；范围扫描则加Next-Key Lock。锁的类型取决于执行路径，但“加锁”这个动作不会跳过。
- RC下不加Gap Lock是默认策略，但Record Lock和Next-Key Lock照常生效
- 锁对象始终是索引记录（聚簇索引或二级索引），不是“表行”
- 若WHERE字段无索引，全表扫描会为每条扫描到的聚簇索引记录都加X Record Lock，效果等同于锁全表
常见误判：EXPLAIN显示rows=0 ≠ 没加锁
很多人看到EXPLAIN输出rows=0就认为“没影响数据，所以不锁”。这是危险误解。InnoDB加锁发生在执行阶段，优化器估算的rows只是预估，不影响实际加锁行为。
例如：UPDATE users SET status = 2 WHERE phone = '13900000000'，phone无索引 → 全表扫描 → 对所有行加X锁；即使最终WHERE条件一行都不匹配，锁也已加上。
- 验证方式：开启事务A执行该UPDATE但不COMMIT，再在事务B中执行
SELECT * FROM users WHERE id = 1 FOR UPDATE，若被阻塞，说明锁已生效 - 真实锁状态必须查
performance_schema.data_locks，不能依赖EXPLAIN或返回的Rows matched - MySQL 8.0+中，
LOCK_MODE字段为X,REC_NOT_GAP即表示纯记录锁，X（无后缀）通常代表Next-Key Lock
RC下加锁与RR的关键差异在哪
核心区别不在“是否加行锁”，而在于“是否额外加Gap Lock”。RC下UPDATE等值查询（主键/唯一索引）只加Record Lock；RR下默认加Next-Key Lock（Record + Gap）。但两者都加Record Lock，这点完全一致。
真正容易踩坑的是：RC下看似“宽松”，却仍会在唯一约束检查、外键引用场景悄悄启用Gap Lock——比如INSERT ... ON DUPLICATE KEY UPDATE，或子表有外键指向该表时的UPDATE操作。
- 主键等值UPDATE在RC下：只锁那一条记录（
X,REC_NOT_GAP） - 非唯一索引等值UPDATE在RC下：仍可能加Next-Key Lock（因需确认“是否还有下一行”）
- 涉及UNIQUE索引冲突检测的语句，在RC下也会触发
X,GAP，这是官方明确允许的行为，不是bug
最常被忽略的一点：锁的粒度永远绑定索引结构。没有索引的UPDATE，无论RC还是RR，实际都是对聚簇索引逐行加锁——它不是“没加锁”，而是加了太多锁，让系统看起来像被表锁卡死。
