什么是当前读和快照读？

在 MySQL InnoDB 中，当前读和快照读是 MVCC 机制下的两种数据读取方式，核心区别在于是否读取最新版本、是否加锁、是否受其他事务影响，二者分工协作实现了 “读写不阻塞” 的高效并发。

一、快照读（Snapshot Read）

核心定义：读取数据的历史版本快照，不走锁机制，完全基于 MVCC 实现。

• 本质：读的是 Undo Log 中存储的历史版本，而非数据页的最新版本。
• 加锁情况：无锁，不会阻塞任何写操作，也不会被写操作阻塞。
• 适用场景：普通的SELECT查询（不加任何锁定子句）。
• 隔离级别影响：
  • 读已提交（RC）：每次SELECT都会生成新的 Read View，可能读到其他事务已提交的最新版本（不可重复读）。
  • 可重复读（RR）：整个事务内共用第一次SELECT生成的 Read View，保证多次读取结果一致。

生活化比喻：你去图书馆查资料，不想等别人归还原版书，直接拿了一本影印版（历史快照）阅读，影印版内容不受原版后续修改影响。

-- 这是典型的快照读 SELECT name FROM user WHERE id = 1;

在之前的事务协作案例中，事务 A 在 T2、T5、T7 执行的SELECT都是快照读，读取的是 Undo Log 里的历史版本（name="张三"），完全不受事务 B 写操作的影响。

二、当前读（Current Read）

核心定义：读取数据的最新版本，且会对读取的记录加锁，保证后续写操作的一致性。

• 本质：读的是数据页的最新版本，需要借助锁机制防止并发冲突。
• 加锁情况：必须加锁，根据操作类型加不同的锁（如行级排他锁、共享锁）。
• 适用场景：所有会修改数据的操作 + 显式加锁的查询，包括：
  1. INSERT/UPDATE/DELETE：修改数据前必须读最新版本，加排他锁（X 锁）。
  2. 显式锁定读：SELECT ... FOR UPDATE（加排他锁）、SELECT ... LOCK IN SHARE MODE（加共享锁）。

生活化比喻：你要修改图书馆的原版书，必须先拿到原版（最新版本），并且拿到后会给书贴个 “正在修改” 的标签（加锁），防止别人同时修改。

-- 显式加排他锁的当前读，读最新版本 SELECT name FROM user WHERE id = 1 FOR UPDATE; -- UPDATE 操作隐含当前读，先读最新版本再加锁修改 UPDATE user SET name = "王五" WHERE id = 1;

在之前的案例中，事务 B 的UPDATE和事务 A 的SELECT ... FOR UPDATE都是当前读，必须读取最新版本（name="李四"），并且加锁防止冲突。

三、当前读 vs 快照读 核心对比表

特性	快照读	当前读
读取版本	历史版本（Undo Log 快照）	最新版本（数据页当前数据）
加锁情况	无锁	必须加锁（X 锁 / S 锁）
阻塞情况	不阻塞写，也不被写阻塞	加 X 锁会阻塞其他写操作，被其他 X 锁阻塞
适用 SQL	普通SELECT	INSERT/UPDATE/DELETE、SELECT ... FOR UPDATE等
依赖机制	MVCC（Read View + Undo Log）	锁机制 + MVCC（仅读取最新版本，不依赖快照）
隔离级别支持	支持 RC、RR	支持所有隔离级别

四、关键补充

1. 为什么当前读不需要 MVCC 快照？当前读的目标是获取最新数据并修改，必须保证数据的 “实时性”，如果读历史版本会导致脏写（比如基于旧版本修改，覆盖了别人的新修改）。因此当前读会跳过 MVCC 的版本链，直接读取最新版本并加锁。

2. 串行化隔离级别下的特殊情况在SERIALIZABLE（串行化）隔离级别下，普通SELECT也会被升级为当前读（隐式加共享锁），此时不再有快照读，所有操作串行执行，完全靠锁保证一致性，并发性能会大幅下降。