快照读不加任何锁，包括意向锁，仅依赖readview和版本链判断数据可见性；当前读则必须加锁并读取最新已提交行，隔离级别仅影响快照读的readview复用策略。

快照读从不加锁，连意向锁都不申请

快照读（比如 SELECT * FROM t WHERE id = 1）完全绕过锁子系统：InnoDB 不会为它申请任何行级锁、间隙锁或意向锁。它只查 ReadView + 版本链，靠 DB_TRX_ID 和 DB_ROLL_PTR 判断可见性。这意味着：

• 并发事务的写操作（UPDATE/DELETE）不会被它阻塞
• 它自己也不会被其他事务的锁阻塞（无等待）
• 即使表上已有 X 锁，快照读仍能立刻返回历史版本

常见误解是“RR 级别下快照读像加了读锁”，其实不是——它只是复用旧 ReadView，跟锁毫无关系。

当前读必须走锁路径，且跳过 MVCC 版本链

当前读（如 SELECT ... FOR UPDATE、UPDATE、DELETE）不看 ReadView，直接定位聚簇索引上最新已提交的物理行，然后按需加锁：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• SELECT ... FOR UPDATE → 对命中的每行加 X 锁（可能附带间隙锁）
• SELECT ... LOCK IN SHARE MODE → 加 S 锁
• UPDATE / DELETE → 先当前读取最新行，再加 X 锁后修改
• 无索引的范围条件（如 WHERE id > 100）会触发全表扫描+全区间加锁，极易引发阻塞

注意：INSERT ... ON DUPLICATE KEY UPDATE 是个特例——它对冲突的唯一键行做当前读并加 X 锁，但对新插入行只加插入意向锁，死锁风险高。

隔离级别只影响快照读的 ReadView 复用策略

很多人以为 RR 和 RC 的加锁行为不同，其实完全错误：

• 所有当前读在 RR 和 RC 下行为一致：都加锁、都读最新已提交行、都可能产生间隙锁
• 真正差异只在快照读：RR 复用事务首次 SELECT 时生成的 ReadView；RC 每次 SELECT 都新建 ReadView
• 所以你在 RR 下两次 SELECT 结果相同，不是因为“锁没释放”，而是 ReadView 没更新；而在 RC 下看到新值，也不是“锁变松”，只是 ReadView 重建了

一个关键副作用：长事务不提交，会让其 ReadView 一直有效，从而阻止 purge 线程清理 undo log，导致历史版本链膨胀、快照读变慢。

容易被忽略的临界点：快照读不加锁，但依赖 undo log 存活

快照读虽不加锁，却强依赖 undo log 中的历史版本。如果长事务拖着不提交，它的 ReadView 会把大量旧版本标记为“仍可见”，导致：

• undo log 无法被 purge 线程回收
• undo tablespace 持续增长，甚至撑爆磁盘
• 版本链变长，每次快照读要遍历更多节点，性能下降明显

这不是锁问题，却是线上最隐蔽的性能雪球——往往等监控报警时，undo 已经几十 GB 了。