数据库脏读幻读不可重复读：隔离级别全解

可视化演示

动态演示数据库脏读幻读不可重复读的核心机制，通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

并发异常总览

Smart Kitchen 开业第一天就乱了套。三位厨师——事务A、B、C——在同一张操作台上忙碌，系统里存着每道菜的状态档案。厨师A在腌鱼，腌到一半去接电话；厨师B路过，看着这条“半成品”还挺像样，顺手拿来做配菜；厨师C则在一旁清点锅具。结果A回来觉得盐放多了，把鱼整个扔掉重做——B 手里那盘配菜瞬间成了“无源之水”。类似的混乱接二连三：B第一次看食材档案是草鱼，转头再看变成了鲈鱼；C数锅数到一半，锅里又凭空多了一口。这三种乱象，就是数据库并发世界里的三大经典异常：脏读、不可重复读、幻读。

它们有一个共同的根源：多个事务并发访问同一份数据时，读写顺序产生了交错。 如果没有规则约束，事务之间就会互相看到“不该看”的中间状态，导致基于错误数据的决策。

厨房管理员意识到，必须出台一套“协作守则”，约束厨师们什么时候能看什么、能碰什么。这套守则，就是事务隔离级别。

隔离级别体系

管理员很快贴出了四套协作守则，供不同场景选用。第一套守则“完全透明”：所有厨师可以看一切半成品，哪怕是别人正在腌的鱼——这叫“读未提交”。第二套守则“只看成品”：半成品一律不许碰，只有做完装盘的菜才能看——这叫“读已提交”。第三套守则“开工拍照”：每位厨师开工时给厨房拍一张全景快照，之后全程只对照照片干活——这叫“可重复读”。第四套守则“交替进场”：同一时间只允许一位厨师在厨房操作，做完下一位才能进——这叫“串行化”。

从第一套到第四套，规则的严格程度逐步升级，能挡住的异常也越来越多。

有了这四套守则，我们再回头细看每一种异常的具体场景、业务危害和避免手段。

脏读详解

厨房里最让人窝火的，就是“半成品陷阱”。厨师B想给套餐配一份葱油鱼，他在系统里看到厨师A的食材档案上写着“鱼：已腌制”，于是放心地按这个状态准备配料。可 A 这边接到电话回来，觉得盐放多了，一个回滚把鱼重新洗过、换料重腌。B 辛辛苦苦备好的配料，全废了。

技术世界里，这就是典型的脏读：事务 T2 读到了事务 T1 尚未提交的修改，而 T1 随后回滚，导致 T2 读取的数据变成了“不存在过的脏数据”。

业务危害很直观：如果库存管理系统 A 事务扣减了库存但未提交，B 事务按这个虚假库存对外承诺“有货”，等 A 回滚后，库存其实没变，但订单已经多签了。避免脏读的办法很简单——把隔离级别至少设为读已提交，让事务只能看到已提交的数据。

不可重复读

第二个场景更隐蔽。厨师B准备做“菜名对照表”，他先查看冰箱第二层的档案：“草鱼”。记录完毕，他去调料架拿了一瓶生抽，回来再看同一份档案——竟然变成了“鲈鱼”。原来厨师C在中间把鱼换了，而且已经提交入库。B 前后两次读的是同一条记录，结果却不同。

这就是不可重复读：同一个事务内，两次读取同一条记录，由于其他事务在中间提交了 UPDATE，两次结果不一致。

业务危害同样惊人：比如在转账场景，T1 先读到账户余额 1000 元用于计算利息，中间 T2 转入 500 元并提交，T1 再结算时余额变成了 1500，导致利息计算错误。避免不可重复读，需要将隔离级别提升到可重复读，或用行锁/共享锁保证读取期间记录不被他人修改。

幻读详解

第三个场景，是最容易和不可重复读混淆的“罗生门”。厨师B负责清点灶台上的锅数，第一次数：5 口，他认真地记在台账本上。等他回头看一眼菜谱，再数一遍——6 口！厨师D在这中间新放了一口锅，并且已经记录在案。B 两次查询的是同一个“范围”（灶台所有锅），但行数变了。

这就是幻读：同一个事务内，两次执行相同的范围查询，由于其他事务在中间插入了新行或删除了旧行，结果集的行数不同。幻读和不可重复读的区别在于：不可重复读是针对某一条已存在的记录，幻读是针对整个记录集合的数量。

避免幻读是三个问题里最麻烦的。可重复读的快照读能挡住一部分，但要对“当前读”（UPDATE/DELETE 这类需要看到最新数据的操作）完全防幻读，需要串行化级别，或者 MySQL InnoDB 在可重复读下使用间隙锁（Gap Lock），把“还未出现的空位”也锁起来，让新数据插不进来。

锁机制基础

厨房为了保证秩序，引入了一套“挂牌制度”。每道菜出锅前可以挂一块牌子：共享锁（S锁） 挂着“试吃”牌——多个厨师可以同时凑过来尝一口，但谁也不能把菜端走；排他锁（X锁） 挂着“制作中”牌——只有持有者能碰这道菜，其他厨师连看都不许看。共享锁之间可以共存（多人试吃不冲突），但共享锁和排他锁、排他锁和排他锁之间水火不容。

锁的粒度也各有讲究：行级锁精细到一盘菜，并发度高；表级锁把整个灶台锁死，简单但性能差；间隙锁则是幻读的克星——它锁住的是“记录之间的空隙”，让新的记录无法插进这个范围。理解了锁，就理解了数据库如何用“排斥”换“一致”。

MVCC原理

锁虽好，但代价太大——读的人多了，写的人就得排队。于是厨房管理员想了个聪明办法：给每道菜装上“时光相机”。系统为每份食材档案维护一串历史版本（版本链），每个版本都用 undo 日志记录着“改之前长什么样”。厨师开工时，系统给他拍一张当时的快照，之后不管别人怎么改这道菜，他看到的始终是开工那一刻的版本——这叫快照读。

但要注意，UPDATE、DELETE、INSERT 这类“当前读”必须看到最新已提交的版本，所以需要加锁。MVCC 的巨大价值在于：普通读操作不加锁、不被写阻塞，在可重复读级别下还能保证一致性快照，这就是为什么现代数据库（MySQL InnoDB、PostgreSQL）都把它作为并发控制的核心底座。

隔离级别选择

不同餐厅有不同经营策略。MySQL InnoDB 默认使用可重复读（RR），一个原因是 MySQL 主从复制在 RR 下更容易保证复制日志的一致性；而 Oracle 和 PostgreSQL 默认使用读已提交（RC），更追求吞吐量和低延迟。选择隔离级别，本质上是在一致性和并发性能之间做权衡。

实际选型时，大部分互联网业务用 RC + 应用层兜底（乐观锁、悲观锁）就足够：比如秒杀系统在 RC 下用 UPDATE 行锁防超卖，不需要 RR 的重型保障。而银行对账、用户余额清算这类强一致场景，才需要升级到 RR 甚至串行化。守住一致性底线，又不牺牲不必要的性能，才是成熟的架构决策。

AI 应用场景

Python 演示

"""模拟数据库脏读 / 不可重复读 / 幻读三类并发问题"""  class MiniDB:    """极简内存数据库：一张余额表和一张订单表"""     def __init__(self):        self.balance = 100          # 余额（已提交值）        self.pending = None         # 未提交的新余额        self.pending_owner = None   # 未提交的事务名        self.orders = [1, 2, 3]     # 订单表，用于幻读演示     def set_balance(self, txn, value):        self.pending = value        self.pending_owner = txn     def commit(self):        if self.pending is not None:            self.balance = self.pending        self.pending = None        self.pending_owner = None     def rollback(self):        self.pending = None        self.pending_owner = None     def read_balance(self, use_pending=False):        if use_pending and self.pending is not None:            return self.pending        return self.balance  def demo_dirty_read():    db = MiniDB()    print("=== 场景1：脏读（读未提交）===")    db.set_balance("T1", 500)    print("T1 把余额改成 500（未提交）")    got = db.read_balance(use_pending=True)    print("T2 读到余额 =", got, "<-- 脏读！")    db.rollback()    print("T1 回滚，余额恢复 =", db.balance)  def demo_unrepeatable_read():    db = MiniDB()    print("\n=== 场景2：不可重复读（读已提交）===")    first = db.read_balance()    db.set_balance("T2", 900)    db.commit()    second = db.read_balance()    print("T1 第一次读 =", first)    print("T2 提交修改后，T1 第二次读 =", second)    print("两次结果不一致 -> 不可重复读")  def demo_phantom():    db = MiniDB()    print("\n=== 场景3：幻读（范围行数变化）===")    n1 = len(db.orders)    db.orders.append(4)    n2 = len(db.orders)    print("T1 第一次数订单数 =", n1)    print("T2 插入一条订单后，T1 再次统计 =", n2)    print("行数变化 -> 幻读")  if __name__ == "__main__":    demo_dirty_read()    demo_unrepeatable_read()    demo_phantom()

1. self.balance = 100保存已提交的正式值，是事务之间“公认的事实”。
2. self.pending = None记录未提交的临时值，代表“半成品”状态。
3. def set_balance(self, txn, value)模拟一个事务修改数据，只写 pending 不写正式值。
4. db.read_balance(use_pending=True)模拟读未提交级别，直接读半成品。
5. db.rollback()模拟回滚，把 pending 清空，正式值保持不变。
6. db.commit()模拟提交，把 pending 正式写入 balance。
7. db.orders.append(4)模拟其他事务插入新行，造成范围结果集变大。
8. if __name__ == "__main__":程序入口，依次执行三个演示函数。

常见误区

面试题