数据库写倾斜与幻读：隔离级别下的并发陷阱

可视化演示

展示写倾斜异常产生原理、幻读范围查询不一致、四种隔离级别异常防范矩阵、SELECT FOR UPDATE等工程防范方案，交互式理解MVCC并发陷阱与隔离级别选择。

并发与隔离：白板的看与写规则

诊所的每一次看白板、写白板，都对应数据库的一次读、一次写。而“隔离级别”就是诊所制定的观看规则：你是能凑到白板前看别人写到一半的草稿（读未提交），还是只能看已经誊写好的最终结果（读已提交），还是进门时给白板拍一张照、之后全程只看这张照片（可重复读），还是干脆规定所有人必须排成单列、一个操作完下一个才能开始（串行化）。

数据库这门“看与写”的学科，围绕一个叫 ACID 的核心承诺展开：原子性、一致性、隔离性、持久性。其中隔离性（Isolation）决定并发时你能看到多少别人的“半成品”。隔离越严格，看到的越真实，但并发能力越差——就像排队看病虽然公平，效率却低。

四类并发异常按严重程度排列：脏读、不可重复读、幻读、写倾斜。隔离级别也分四档阶梯：读未提交（RU）、读已提交（RC）、可重复读（RR）、串行化（SR）。RC 防住脏读，RR 让快照读稳定，SR 则防住一切异常。这四档的关系，决定了后面两个陷阱出现的舞台。

规则越严，白板前越安全，但排队的队伍也越长。值得记住的是：MySQL InnoDB 默认 RR，PostgreSQL 默认 RC——默认档位不同，踩坑的概率也不同。理解这四档，是通向后面两个陷阱的入场券。

写倾斜原理：两个医生同时下班

回到开头那场事故。李医生的操作能拆成三步：看一眼白板（读）；判断“赵医生还在岗，我可以走”（计算）；擦掉自己的名字（写自己的行）。赵医生也一模一样。问题出在第一步：两人看的都是“进门时”的信息——在可重复读/快照隔离下，他们各拿着一张旧照片，照片上对方都还在岗。

数据库术语里，这叫作写倾斜（Write Skew）：两个事务读了相同的行集，却写了不相交的行集，最终联合破坏了跨多行的业务约束。最阴险的是，全程没有任何锁冲突——两人锁的是不同的行，谁也不等谁，所以没有死锁、没有超时、没有报错，双方都愉快地提交了。等到应用层再去查“为什么没人值班”，事故早已发生。

写倾斜的配方恰好三个要素：共同的读集、不相交的写集、全表性的约束。快照隔离保证了“读一致”，却管不住“基于旧数据做出的判断”。它不像脏读那样明显，也不像死锁那样会报错，是并发数据库里最隐蔽的坑之一。

两人都拿着同一天拍的合影，照片里对方还在值班室，于是各自放心地关灯走人——白板最终空无一人。要阻止这场事故，光靠“发照片”的隔离级别不够，必须改变“读判断”与“写”之间的锁联动方式。

幻读原理：候诊名单上多出的病人

诊所角落里，护士长正在做重要统计：今晚 3 点以后挂号的病人有多少？她第一次数，候诊名单上有 3 位。正要录入，急救电话响起，新病人被推进来挂号——名字被写进名单。护士长回头再数一遍：4 位。名单上的旧行一行动过，却凭空多出一行。这个“多出来的幻影”，就是幻读（Phantom Read）。

幻读的本质是：同一事务内，同一条谓词查询（WHERE 条件），两次执行的结果集变了。它和不可重复读的区别在于：不可重复读是“同一行的内容变了”，幻读是“满足条件的行数变了——多出来或消失了”。引发幻读的操作几乎总是 INSERT 或 DELETE，而不是 UPDATE。

为什么快照读能防住它？在可重复读的快照机制下，护士长第二次数的确实还是旧名单。但如果她用的是“当前读”（加锁读），比如 SELECT …… FOR UPDATE 或 UPDATE …… WHERE，数据库必须看最新数据，此时并发插入的新行就像幽灵一样混了进来。MySQL InnoDB 用“间隙锁”给谓词区间筑墙；没有间隙锁的数据库，在 RR 下仍可能被幻读偷袭。

名单上每条记录都真实存在，但“两次统计结论不同”这件事本身，会让护士长做出错误的排班决策。幻读最危险的地方在于：它骗过你的眼睛，让你基于错误的总数做判断。

两者区别：擦名字 vs 加名字

写倾斜和幻读，就像白板上的两类破坏：一类是“把已有的名字擦掉”（更新行值），一类是“悄悄添上新的名字”（插入新行）。一个改变字的颜色，一个改变名单的长度。很多初学者把两者混为一谈，其实它们发生的路径和防护手段完全不同。

从数据库角度看有三点区别。第一，操作类型：写倾斜是两个 UPDATE 作用于不同的行；幻读是一个 INSERT 引入了新行。第二，读取方式：写倾斜依赖快照读的旧数据做判断；幻读出现在对谓词区间重复执行查询时。第三，约束性质：写倾斜破坏的是“跨多行的业务约束”，幻读破坏的是“查询结果集的稳定性”。

正因为不同，防护手段也不同：写倾斜需要把“读判断”变成加锁读写，或锁住一条物化的控制行；幻读需要锁住谓词对应的整个值域区间（间隙锁），或者直接上串行化。用错手段会事倍功半——例如只给写倾斜加行锁完全无效，因为你锁的是自己正在改的行，而对方改的是另一行。

给白板“每一行”上锁（行锁），管得住有人偷偷改你的名字，却管不住护士在名单末尾新登记一位病人。想同时防住两件事，得把“行”和“范围”两个维度都锁住。

隔离防护：从窗帘到铁门

诊所可以选择不同防护等级。RC 像半透明的窗帘，能拦住别人写到一半的草稿，但挡不住你看完一遍后内容又变。RR 像进门时发一张照片，看照片稳定，但照片总会过时。SR 则是铁门加登记处：所有人排成单列，一个接一个操作白板，任何并发事故都无从发生。

串行化的定义很漂亮：并发执行的效果，等价于把事务按某种顺序一个个执行。它不要求数据库真的一个一个来，而是保证“结果像排过队”一样。PostgreSQL 的 SERIALIZABLE 采用 SSI（可串行化快照隔离），通过检测读写依赖并主动中止一个事务来拦下写倾斜；MySQL InnoDB 的 RR 则用“间隙锁 + 行锁”组成 next-key 锁，在加锁读时锁住整个谓词区间。

间隙锁的精髓在于：它锁的是一个值区间 (a,b)，即使区间里现在一行数据都没有，也能阻止未来插入。这就像护士长在“3 点到 5 点”的时段格里插了一面小旗：新病人的挂号单若落在这时段，必须等小旗撤掉。而写倾斜的防护，要靠显式地把“读+判断”变成加锁的原子步骤，或用版本号做乐观锁重试。

隔离级别不是越高越好，而是越贴合业务风险越好。高风险规则用铁门，普通查询用窗帘——取舍之道，在于理解每一档真正防住了什么、漏掉了什么。

MVCC 支撑：白板背后的便利贴层

为什么快照读能这么稳定？因为数据库并没有真的把旧字擦掉。想象白板背后藏着一摞便利贴：每次有人改名，只是把一张新便利贴贴上去，旧的还压在下面。每张便利贴都标着“谁贴的、第几张”。医生进门时，护士长递给他一副特殊眼镜——戴上后，他只看得见“贴得早于他进门”的便利贴，后来的新贴纸统统隐形。这副眼镜，就是 MVCC（多版本并发控制）。

MVCC 的表里，每一行都维护着多个历史版本，串成一条“版本链”。新增的隐藏字段包括事务 ID（trx_id）和回滚指针（roll_pointer）。每次 UPDATE 不是覆盖，而是生成新版本，通过回滚指针指向前一版，形成链表。事务做“快照读”时，按自己的快照 ID 沿链找第一个可见版本；做“当前读”时，绕过快照直接读最新已提交版本并加锁。

可见性判定的核心就一句话：只要这个版本的事务 ID 不晚于你的快照点，且没有删除标记，你就看得见。正是这种“按版本筛选”的机制，让快照读永远稳定——但代价是，一个事务永远感知不到快照之后别人提交的新版本，写倾斜的温床就此形成。MVCC 是利也是弊：它让读写互不阻塞、读性能极高，但“基于旧判断的写”可能悄悄破坏约束。

便利贴层让“看”飞快且稳定，但也意味着你看到的世界永远滞后一步。写倾斜的根，就埋在“滞后”这两个字里——而理解这一点，是选择防护方案的前提。

实战对策：让值班表不再失控

护士长决定改革，拿出三样工具：第一样是“手按白板”——医生做判断时，必须用手按住相关区域，别人只能等他写完再看（悲观锁）；第二样是“带编号的便利贴”——每次写都要先核对编号，发现编号被别人改过就撕掉重来（乐观锁）；第三样是“值班哨岗”——把“至少一人在岗”这条规则物化成哨岗登记表，谁进谁出都必须先动哨岗那行记录。

三种工具对应数据库世界的经典解法。悲观锁：SELECT …… FOR UPDATE 把“读判断”变成加锁的当前读，命中行被加排他锁直到事务结束。乐观锁：加 version 字段，UPDATE 时带 WHERE version = 读到的值，影响行数为 0 说明冲突，重试即可。物化冲突：把多行约束浓缩成一行“控制行”，锁这行就等价于锁整个规则。

工程实践还要注意：加了锁可能死锁（互相等待形成环），数据库靠等待超时和死锁检测处理，被牺牲的事务抛出异常，应用层要设计重试；锁粒度太粗会拖垮并发，需要监控锁等待时间、死锁次数、冲突率。SQL 层面，EXPLAIN 能确认 UPDATE 是否走索引——锁的范围随索引而定，全表扫描会锁全表，这也是排查“锁风暴”的钥匙。

白板的秩序，终究要靠“看”与“写”的纪律来保证。选择悲观锁还是乐观锁，本质是选择“宁可排队”还是“宁可重试”——没有银弹，只有对业务并发模式的清醒认知。

AI 应用场景

Python 演示

import threadingimport time # 值班白板: 模拟数据库中的两行数据roster = {'李': True, '赵': True}  def transaction(doctor, use_lock=False, lock=None):    """模拟一个事务: 快照读 -> 业务判断 -> 写自己的行。"""    if use_lock:        lock.acquire()           # 悲观锁: 把判断和写变成临界区    try:        snapshot = dict(roster)  # 事务开始时的快照读        time.sleep(0.02)         # 放大并发窗口, 让两个事务互相交错        other_on = [d for d, v in snapshot.items() if d != doctor and v]        if other_on:             # 快照里还有别人在岗            roster[doctor] = False   # 只写自己的行            return doctor + ' 看到' + other_on[0] + '在岗, 已下班'        return doctor + ' 发现无人留守, 留下值班'    finally:        if use_lock:            lock.release()  def run_demo(use_lock=False):    global roster    roster = {'李': True, '赵': True}    lock = threading.Lock() if use_lock else None    t1 = threading.Thread(target=transaction, args=('李', use_lock, lock))    t2 = threading.Thread(target=transaction, args=('赵', use_lock, lock))    t1.start()    t2.start()    t1.join()    t2.join()    on_call = [d for d, v in roster.items() if v]    if on_call:        return '最终在岗: ' + '、'.join(on_call)    return '最终在岗: 空无一人!'  if __name__ == '__main__':    print('[不加锁: 快照隔离下的写倾斜]')    print(run_demo(False))    print()    print('[加锁: 判断与写入被串行化]')    print(run_demo(True))

1. snapshot = dict(roster)事务开始瞬间把整张表复制成“快照”，之后的判断全部基于这份旧数据，这正是写倾斜的温床。
2. time.sleep(0.02)人为放大两个事务的交错窗口，让现实中一闪而过的竞态稳定复现。
3. roster[doctor] = False每个事务只写“自己的行”，互不冲突，因此两个写都能成功提交。
4. lock.acquire()悲观锁把“读 + 判断 + 写”变成临界区，李的判断结果立刻对赵可见。
5. run_demo(use_lock=False)对照组：无锁复现写倾斜，加锁后约束恢复，输出对比一目了然。

常见误区

面试题