Atopos

1. 脏读（Dirty Read）——读到「临时变卦」的数据

一句话定义：

一个事务读取了另一个尚未提交的事务修改过的数据。

「尚未提交」意味着这个数据随时可能被回滚。读到这种数据，就像看了一张还没定稿的草稿纸——你当真了，但它其实是「脏」的。

场景再现：

把上面的银行场景细化一下：

小李在 T4 时刻读到了 0 元，但小张在 T5 回滚了。 0 元从未真正存在过——它是一个「脏数据」。

为什么叫「脏读」？

因为这个数据是「不洁的」——它来自于一个还未确定的事务，随时可能被擦掉（回滚）。就像从垃圾桶里捡起一张写了半截的支票，以为能兑付，结果人家根本没签完。

对业务的影响（这部分最重要，请仔细看）：

柜员小李读到余额为 0 后，可能做了以下事情：

• 告诉客户：「您的余额不足，转账失败」→ 客户投诉
• 拒绝了一笔贷款申请 → 银行失去一个客户
• 在系统里记录了一条「余额不足」的日志 → 后续审计出问题

而这一切，都建立在一个「从未真实存在过」的数据之上。

总结：脏读的本质是「读到未提交的数据」。解决脏读，就是禁止读取未提交的数据。

2. 不可重复读（Non-Repeatable Read）——两次读取「翻脸不认人」

一句话定义：

一个事务内两次读取同一行数据，得到的结果不同。

「不可重复读」这个名字很直白——同样的查询，重复做，读出来的东西不一样。

场景再现：

同一个事务（小李的事务）内，两次读取同一行数据，结果从 100 变成了 0。

脏读 vs 不可重复读（重点区分）：

打个比方：

• 脏读：你看到同事屏幕上写了一半的文档，以为定稿了 —— 结果他删掉了。
• 不可重复读：你打印了一份文档，同事修改后重新打印了一份，你手上两份不一样。

对业务的影响：

小李第一次查询余额为 100 元，据此做了一份财务报告。第二次查询发现是 0 元，报告作废。

更严重的场景：小李第一次查询后，批准了一笔以「余额 100 元」为担保的贷款。第二次查询发现余额为 0，贷款已经放出去了。

总结：不可重复读的本质是「事务内多次读取不一致」。解决不可重复读，就是保证事务内多次读取同一数据的结果不变。

3. 幻读（Phantom Read）——数据「凭空出现」或「突然消失」

一句话定义：

一个事务内两次查询同一范围的数据，结果集的行数不同。

「幻读」这个名字很形象——多出来的那行数据，就像「幻影」一样凭空出现。

场景再现：

同一个事务内，两次查询同一条件，行数从 3 变成了 4。

多出来的那一行，就像「幻影」一样。

不可重复读 vs 幻读（重点区分）：

打个比方（继续用文档的比喻）：

• 不可重复读：文档内容被修改了，你手上的版本和最新版本不一样。
• 幻读：文档里凭空多了一段话，或者少了一段话，你数了数段落数对不上。

对业务的影响：

小李统计「余额大于 0 的账户数」为 3 个，据此做了资金分配方案。执行时发现多了一个账户（赵六），方案需要重新制定。

电商场景：运营人员统计「待发货订单」为 10 笔，准备批量处理。处理过程中，用户又下了 1 笔新订单，结果漏掉了这笔。

总结：幻读的本质是「事务内数据行数变化」。解决幻读，就是防止事务执行期间其他事务插入或删除影响结果集的数据。

隔离级别的整体阶梯

从低到高，依次是：

安全性从低到高，性能从高到低——这是一个经典 trade-off（权衡）。

⚠️ 关于 Repeatable Read 和幻读：MySQL 的 InnoDB 引擎通过「间隙锁（Gap Lock）」机制，在 Repeatable Read 级别下也基本避免了幻读。这个我们会在第 3 篇详细讲。

各个隔离级别详解

不同数据库的默认隔离级别（常识积累）

面试中常问：「为什么 MySQL 用 Repeatable Read，而 Oracle 用 Read Committed？」——历史原因 + MySQL 的 InnoDB 通过间隙锁在 RR 下也能避免幻读，所以选择 RR 作为默认值。

准备工作

查看当前隔离级别：

1
-- MySQL 8.x 查看当前会话的隔离级别
2
SELECT @@transaction_isolation;
3

4
-- 或者
5
SHOW VARIABLES LIKE 'transaction_isolation%';

设置隔离级别：

1
-- 设置当前会话的隔离级别（推荐，不影响其他连接）
2
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
3

4
-- 设置全局隔离级别（影响所有新连接，需要权限）
5
SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;

⚠️ 致命提醒：设置隔离级别必须在开启事务之前！一旦执行了 BEGIN;，再修改隔离级别就不生效了。

数据准备：

1
-- 确保只有一条记录
2
DELETE FROM account;
3
INSERT INTO account VALUES (1, '张三', 100);

演示一：Read Uncommitted —— 亲眼看到脏读

目标： 演示一个事务如何读到另一个事务未提交的数据。

Step 1：两个终端都设置隔离级别

1
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

Step 2：终端A 开启事务，修改张三余额但不提交

1
BEGIN;
2
UPDATE account SET balance = 0 WHERE id = 1;

现在张三的余额在终端A中变成了 0，但事务还没提交。

Step 3：终端B 查询张三余额

1
SELECT * FROM account WHERE id = 1;

关键来了： 终端B 读到的 0，是终端A 还没确定的数据（可能回滚）。

Step 4：终端A 回滚事务

1
ROLLBACK;

Step 5：终端B 再次查询

1
SELECT * FROM account WHERE id = 1;

结果展示：

1
终端B 第一次查询：balance = 0  ← 读到脏数据
2
终端B 第二次查询：balance = 100 ← 回滚后恢复

结论： Read Uncommitted 允许脏读。终端B 读到的是一个「从未真实存在过」的数据。

对业务的影响： 柜员小李看到余额为 0，拒绝了客户的取款请求。但实际上张三是 100 元，只是因为小张的操作还没完成。这就是脏读带来的真实业务风险。

演示二：Read Committed —— 脏读消失，但不可重复读出现

目标： 演示 Read Committed 如何避免脏读，以及它为什么仍会有不可重复读。

Step 1：两个终端切换隔离级别

1
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

Step 2：终端B 开启事务，第一次查询

1
BEGIN;
2
SELECT * FROM account WHERE id = 1;

Step 3：终端A 修改并提交

1
BEGIN;
2
UPDATE account SET balance = 0 WHERE id = 1;
3
COMMIT;

Step 4：终端B 同一个事务内第二次查询

1
SELECT * FROM account WHERE id = 1;

结果展示：

1
终端B 第一次查询（事务内）：balance = 100
2
终端B 第二次查询（同一事务内）：balance = 0  ← 不可重复读发生！

结论： Read Committed 避免了脏读（读不到未提交的数据），但无法避免不可重复读（同一事务内两次查询结果不同）。

对业务的影响： 柜员小李在同一个事务里，第一次看到 100 元，第二次看到 0 元。如果她第一次查询后做了财务记录，第二次查询后需要推翻重来。

演示三：Repeatable Read —— 不可重复读消失

目标： 演示 Repeatable Read 如何让事务内多次读取结果一致。

Step 1：两个终端切换隔离级别

1
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Step 2：终端B 开启事务，第一次查询

1
BEGIN;
2
SELECT * FROM account WHERE id = 1;

Step 3：终端A 修改并提交

1
BEGIN;
2
UPDATE account SET balance = 0 WHERE id = 1;
3
COMMIT;

Step 4：终端B 同一个事务内第二次查询

1
SELECT * FROM account WHERE id = 1;

Step 5：终端B 提交事务，再次查询

1
COMMIT;
2
SELECT * FROM account WHERE id = 1;

结果展示：

1
终端B 事务内第一次查询：balance = 100
2
终端B 事务内第二次查询：balance = 100 ← 没变！
3
终端B 提交后再查：balance = 0 ← 事务结束后才看到新数据

结论： Repeatable Read 保证了事务内多次读取同一数据结果一致——即使其他事务已经提交了修改。

对业务的影响： 柜员小李在整个事务期间，看到的是一个「稳定快照」——无论小张怎么改，小李看到的数据始终是事务开始时的状态。这保证了决策的一致性。她提交事务后，才能看到最新的数据。

演示四：Serializable —— 最强隔离，完全串行

目标： 演示 Serializable 如何通过「排队执行」避免所有并发问题。

Step 1：两个终端切换隔离级别

1
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Step 2：终端B 开启事务，查询数据

1
BEGIN;
2
SELECT * FROM account WHERE id = 1;

Step 3：终端A 尝试修改数据

1
BEGIN;
2
UPDATE account SET balance = 0 WHERE id = 1;

此时终端A 被阻塞（等待中），因为终端B 的读锁还没释放。

Step 4：终端B 提交事务

1
COMMIT;

终端A 的 UPDATE 立即执行成功。

结果展示：

1
终端B 持有读锁 → 终端A 的 UPDATE 被阻塞
2
终端B 提交 → 终端A 的 UPDATE 才执行

结论： Serializable 通过强制串行执行，避免了所有并发问题，但代价是并发性能极低——所有操作排队。

对业务的影响： 银行核心账务中的某些操作，宁可慢，也不能错。Serializable 提供了「绝对正确」，但代价是其他人需要等待。

隔离级别相关命令

1
-- 查看当前会话隔离级别
2
SELECT @@transaction_isolation;
3

4
-- 设置当前会话隔离级别
5
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
6
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
7
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
8
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

演示中使用的数据

1
-- 初始化数据
2
DELETE FROM account;
3
INSERT INTO account VALUES (1, '张三', 100);
4

5
-- 查看数据
6
SELECT * FROM account;
7

8
-- 清空数据（重新演示用）
9
TRUNCATE account;

核心知识点回顾

隔离级别速记表

一句话记住全部

脏读是读到了「未决定」的数据，不可重复读是「同一行数据变了」，幻读是「行数变了」。

Read Uncommitted 全都不防，Read Committed 防脏读，Repeatable Read 防脏读+不可重复读，Serializable 全都防。

下篇预告

本文我们用「张三的余额」作为线索，演示了四种隔离级别的差异。

但你可能会问：

• Repeatable Read 是怎么做到的？ 为什么终端A已经提交了，终端B还是读不到？
• MySQL 在 Repeatable Read 下，到底有没有解决幻读？怎么解决的？
• 锁和 MVCC 到底是什么关系？