事务隔离级别选错导致数据被吞 脏读幻读一次讲透

你在开发过程中，有没有遇到过这样的情况：一个事务里查了两次同样的数据，结果居然不一样；或者查了两次同样的范围条件，结果集凭空多了一行？很多人第一反应是“是不是缓存出问题了”，但其实，更大的概率是事务隔离级别没选对。

事务隔离级别，简单来说就是决定多个事务同时运行时，彼此能看到多少对方的数据。选得太低，数据可能被“污染”；选得太高，并发性能又会急剧下降。今天这篇文章，我们就从四个隔离级别出发，把脏读、不可重复读、幻读这三个概念，掰开揉碎讲清楚。

先搞懂四个隔离级别

SQL标准定义了四种隔离级别，从低到高依次是：

1. READ UNCOMMITTED（读未提交） ——级别最低。事务可以读取其他事务尚未提交的数据。几乎不提供任何并发控制，实际生产环境中极少见到它的身影。

2. READ COMMITTED（读已提交，简称RC） ——只能读取其他事务已经提交的数据。它成功避免了脏读，但无法避免不可重复读。

3. REPEATABLE READ（可重复读，简称RR） ——保证同一事务内多次读取同一数据，结果完全一致。这也是MySQL InnoDB的默认隔离级别。

4. SERIALIZABLE（可串行化） ——最高级别，事务完全串行执行，从根源上杜绝所有并发问题，但性能开销也是最大的。

不同隔离级别能解决的问题，可以浓缩成下面这张表：

三种并发问题，用真实SQL讲清楚

脏读：读到别人“还没想好”的数据

脏读，指的是一个事务读取了另一个事务尚未提交的修改。如果那个事务最终回滚了，你读到的就是“脏数据”——从未真正存在过的数据。

用电商库存场景来理解：事务A开始扣减库存，把商品X的库存从100改为99，但还没提交；此时事务B查询库存，读到了99。如果事务A因支付失败回滚了，库存恢复为100，但事务B已经基于99做了后续操作——超卖了。

-- 事务A（未提交）
START TRANSACTION;
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- stock从100变99
-- 此时事务B读取到stock=99（未提交的数据）
-- 事务A回滚
ROLLBACK;  -- stock恢复为100，但事务B已经用了99的数据

想要解决脏读，至少要把隔离级别设置为READ COMMITTED。

不可重复读：同一事务内，数据“变了”

不可重复读指的是在同一个事务内，多次读取同一数据时结果不一致。它与脏读的关键区别在于：脏读读的是未提交的数据，而不可重复读读的是已提交的数据。

用财务场景来理解：财务人员在事务A中查询员工张三的工资，第一次看到5000元；此时HR在事务B中给张三加薪至6000元并提交；事务A再次查询时，工资变成了6000元。同一个事务里两次查询结果不一样——这就是不可重复读。

-- 事务A（隔离级别READ COMMITTED）
START TRANSACTION;
SELECT salary FROM employees WHERE id = 1;  -- 返回5000

-- 事务B（同时执行）
START TRANSACTION;
UPDATE employees SET salary = 6000 WHERE id = 1;
COMMIT;  -- 提交修改

-- 事务A再次查询
SELECT salary FROM employees WHERE id = 1;  -- 返回6000，和第一次不一样
COMMIT;

READ COMMITTED级别无法避免这个问题。你需要升级到REPEATABLE READ。

幻读：结果集“凭空多了一行”

幻读指的是在同一个事务内，多次查询某个范围的数据时，结果集的数量发生了变化——第一次查有5行，第二次查变成了6行。

打个比方：你在图书馆按分类找书，第一次看到书架上有5本书；等你转了一圈回来再数，变成了6本——多出来那本就是你不在的时候别人放上去的。

-- 事务A（隔离级别REPEATABLE READ）
START TRANSACTION;
SELECT * FROM orders WHERE status = 'pending';  -- 返回5行

-- 事务B（同时执行）
START TRANSACTION;
INSERT INTO orders (id, status) VALUES (100, 'pending');
COMMIT;

-- 事务A再次查询
SELECT * FROM orders WHERE status = 'pending';  -- 返回6行，多了一行！
COMMIT;

MySQL的RR为什么能“基本避免”幻读？

按照SQL标准，REPEATABLE READ级别实际上是允许幻读的。但MySQL InnoDB通过MVCC（多版本并发控制）+ Gap Lock（间隙锁） 的组合拳，在绝大多数场景下实实在在地避免了幻读的发生。

• ​MVCC​：事务开始时拍一次快照，后续的普通SELECT都基于这个快照来读，别人提交了新数据你也看不到。
• Gap Lock（间隙锁）：锁定索引记录之间的空隙，阻止其他事务在范围内插入新行。

但有一点需要特别留意：​DML语句（UPDATE/DELETE）不遵循快照读​，它们可能会看到其他事务刚提交的行。所以在某些边缘场景下，RR级别仍然有可能出现幻读。

MySQL vs PostgreSQL：默认隔离级别为什么不同？

这是一个容易被忽略，但非常重要的差异。

• MySQL InnoDB默认使用REPEATABLE READ（RR）
• PostgreSQL默认使用READ COMMITTED（RC）

为什么？答案在于两者MVCC的实现机制不同：

MySQL选择RR作为默认级别，是为了在并发性能和数据一致性之间取得一个较好的平衡，适合绝大多数互联网业务场景。PostgreSQL选择RC作为默认，则是因为它在RR级别下对幻读的处理更加严格，反而可能导致更多的死锁问题。

业务场景中怎么选隔离级别？

一条核心的选型原则是：不是隔离级别越高就越好。隔离级别越高，并发性能越低。你需要根据业务对一致性和性能的实际要求来做权衡。

实战避坑：两个常见的隔离级别陷阱

陷阱1：在RC级别下做“先查后改”

很多业务逻辑都是“先查询状态，再根据状态做更新”。在RC级别下，两次查询之间数据可能被其他事务修改，导致“查的时候是A，改的时候已经变成B了”——数据就这样被“吞”掉了。解决方案：要么使用RR级别，要么在查询时加上FOR UPDATE把数据锁住。

陷阱2：RR级别下的间隙锁导致死锁

RR级别通过间隙锁成功避免了幻读，但间隙锁本身也是死锁的常见来源。在RR级别下做范围删除或范围更新，很可能锁住大量不存在的“间隙”，导致多个事务互相等待，最终形成死锁。如果你的业务场景不需要防止幻读，不妨考虑降级到RC级别，牺牲一点一致性来换取更高的并发性能。

总结

事务隔离级别是数据库并发控制的核心机制，直接影响数据的正确性和系统的吞吐量。透彻理解脏读、不可重复读、幻读的本质差异，搞清楚MySQL为什么选择RR、PostgreSQL为什么选择RC作为默认值，你就能在实际业务场景中做出更合理的选择，写出更可靠、更高效的事务代码。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：事务隔离级别选错导致数据被吞 脏读幻读一次讲透要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题