分布式存储引擎：MVCC多版本并发控制

可视化演示

演示数据库MVCC为每行数据维护多个版本快照实现读写互不阻塞，展示版本链结构、事务可见性判定与垃圾回收机制，并对比2PL的隔离级别差异。

并发控制概述：从“借书上锁”到“多版本并存”

图书馆旧制度：一本书只有一册，谁要借走抄写，馆员就把书锁进柜台。你借我就得等，你还了我才能看。数据库初期的并发控制也是这套“借书上锁”逻辑——读要锁、写要锁，读写一相遇，总有一方在排队。排队的代价不只是慢：锁等待可能引发死锁，死锁又要回滚重试，高并发下系统吞吐直线下滑。

数据库里的“读者”是 SELECT，“写者”是 UPDATE。早期的 2PL（两阶段锁）协议靠加锁保证一致性，但本质是拿互斥换安全。工程师们开始反问：为什么非要让读者和写者抢同一册书？能不能让书架上同时摆着新旧两册——读者看旧的，写者在后台改新的？

MVCC（Multi-Version Concurrency Control，多版本并发控制）给出了答案：每行数据保存多个历史版本，UPDATE 产生新版本而不是覆盖旧值，SELECT 按事务快照选定一个版本读取。读写因此彻底解耦：读永不等待，只有写写冲突时才需要锁。MySQL InnoDB、TiDB、CockroachDB 等主流存储引擎，都把 MVCC 作为并发控制的基石。

用时间换空间，还是用空间换时间？MVCC 选择了后者——用一小块额外存储（版本）+ 每次读的定位成本，换掉锁等待的全部代价。读多写少的场景下，这笔交易稳赚不赔。

就像图书馆允许“看旧改新”，MVCC 用一小块额外存储换来了并发度的大幅提升。理解了“为什么不直接覆盖、而要留着旧版本”，你就握住了整套多版本制度的第一把钥匙。

版本链结构：每本书背后的“修订史架”

修订史架上的每册书都盖着三个章：书的原始流水号、这次修订的编号、以及“上一版放在哪”的便签。顺着便签一路翻，就能从最新版回溯到初版。这个设计聪明在：新修订不用搬动旧书，只需要在旧册上贴一张指向自己的便签。

数据库行记录同样藏着三个隐藏字段：DB_ROW_ID（隐藏主键，未显式声明主键时的行标识）、DB_TRX_ID（最近修改本行的事务编号）、DB_ROLL_PTR（回滚指针，指向上一个版本）。它们对 SQL 不可见，却是 MVCC 运行的地基——就像修订章对读者不可见，但对馆员是账本的根本。

一次 UPDATE 的执行路径：先把当前行的旧值连同版本信息写入 undo log，让新行的 DB_ROLL_PTR 指向它，再把新值写到行上作为新的链头。旧版本并没有被删，而是“退居二线”挂到了链上。版本链因此越长，可回溯的历史越深，但也埋下了清理的伏笔。

修订史架上的每一册都放得下“上一册在哪”的便签，数据库的每个版本节点也都带着回滚指针。理解了版本链，你就明白“旧数据”并不是被删掉，而是被推到了链的更深处——这也为后面的垃圾回收埋下了伏笔。

快照与可见性：馆员的“借阅凭证规则”

读者进门，馆员递上一张借阅凭证，上面记着：此刻正在贵宾室赶稿的名单、以及最早和最晚的修订编号。此后无论书架上怎么变，馆员只认凭证不认现场。你攥着这张纸，看到的就是盖章那一刻的世界。

这张凭证就是 ReadView。快照读（普通 SELECT）在事务内第一次执行时生成 ReadView，记录三样东西：m_ids（此刻活跃事务编号集合）、min_trx_id（m_ids 中的最小值，即最早活跃编号）、max_trx_id（下一个待分配的编号）。有了它，馆员沿版本链逐册检查，决定哪一册能看。

判定规则按优先级分四档：第一，事务编号小于 min_trx_id，快照前就提交了，直接可见；第二，编号在 m_ids 名单里，正在执行未提交，不可见；第三，编号大于等于 max_trx_id，快照之后才开局，不可见；第四，其余情况——晚于快照但已提交落定，可见。四档判据，覆盖了版本的一切可能处境。

快照读之外还有“当前读”（SELECT …… FOR UPDATE、UPDATE、DELETE）：它读最新已提交数据并加锁，相当于跑到修订间门口现场核对。快照读看凭证，当前读看现场——理解了这对组合，你就理解了 MVCC 与 2PL 是如何在同一引擎里分工合作的。

垃圾回收：馆员的“定期清旧书”

修订版越积越多，书架早晚爆掉。馆员每天闭馆后推车清点：凡是没有读者凭证还可能引用的旧册，就下架回收入库。注意关键词——“没有凭证引用”：只要还有一张旧凭证没失效，旧书就得继续留在架上。

数据库的回收由后台 purge 线程负责。它维护一条“回收水位线”：取所有存活快照中最老的 min_trx_id。版本事务编号低于水位、并且不是链头的版本，说明任何快照都不再需要“越过”它去读更旧的值，可以安全物理删除。水位线往前推一寸，历史列表就短一寸。

长事务是回收的天敌。一个 40 分钟不提交的事务，会把水位线死死按在它开始的位置，期间每一次更新产生的旧版本都无法回收，undo log 越长、版本链越深、查询越慢。运维监控里 history list length 持续上涨，十有八九是有人攥着旧凭证不还。

回收调优的抓手：innodb_purge_threads 提高清理并行度，控制批量大小减少每次停顿；应用侧则要避免大事务、及时提交、拆分长事务。书架清理从来不只是馆员勤快的问题，更是读者自觉的问题。

长事务一多，回收小车就推不动，书架随之爆满。所以 MVCC 世界里有个铁律：快照持有时间越短，系统越健康。谁攥着旧凭证不撒手，谁就是在帮版本堆积“续命”。

隔离级别对比：两种“阅览制度”

图书馆有两种阅览制度：普通阅览室每次进门盖新章、凭证当场作废；贵宾室一证到底，全程只看初进门那一刻的世界。数据库的两种常用隔离级别，恰好对应这两种制度。

READ COMMITTED（读已提交）：每条快照读语句都新建 ReadView，凭证一直换新，所以能看到别的事务刚刚提交的新版本。REPEATABLE READ（可重复读）：事务内首次快照读生成 ReadView 后反复复用，世界定格在首读瞬间，之后别人再怎么提交，这里都看到同一片风景——这就是“可重复读”名字的由来。

快照读解决了“读旧”，当前读怎么办？REPEATABLE READ 下，快照读管不住“新插入的行”，InnoDB 用 next-key lock（记录锁 + 间隙锁）锁住扫描范围来防止幻读。所以完整答案是：MVCC 负责快照读的一致性，2PL 负责当前写的互斥，两者拼在一起才是完整的隔离级别。

贵宾室的“一证到底”听着高级，代价却是事务拖得越久、回收水位卡得越久。选 RC 还是 RR，取决于业务要“每次都看最新”，还是要“一次看见、始终一致”——以及你受不受得了旧版本堆积的风险。

工程实践：图书馆的“事故复盘”

深夜，图书馆告警：修订史架爆满。值班馆员一查，3 号贵宾室有位读者凭证盖的还是 40 分钟前的章，推车的小车根本推不动。这是 MVCC 生产事故最常见的剧本——长事务卡死回收水位，版本链无限膨胀。

高并发热点更新的另一种剧本：秒杀场景下库存行每秒被改上千次，版本链疯狂加长，每条快照读都要沿链回溯，性能随之劣化。对策不外乎三板斧：缩短事务时长、拆分热点行（库存分散到多个子行）、控制批量更新粒度。监控指标盯住 version chain length 与 history list length，趋势比绝对值更有说服力。

排障流程同样有章法：先查 information_schema.innodb_trx 找出长时间未提交的事务；再看 SHOW ENGINE INNODB STATUS 中的 History list length 和 purge 状态；最后用 performance_schema 定位持锁语句与 undo 暴涨来源。设计决策上，读多写少、追求高并发读的系统优先选 MVCC 引擎；写冲突密集、强一致的关键路径，则要让 2PL 显式锁做兜底。

修订史架爆满的根源从来不只在书架本身——要么书改动太快，要么有人攥着旧凭证不肯还。理解了 MVCC 的全链条，排查类似故障时你就能一眼锁定“版本链太长”还是“水位被卡死”。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-# 迷你 MVCC 引擎: 用版本链和 ReadView 实现多版本并发控制class Version:    def __init__(self, trx_id, value):        self.trx_id = trx_id      # 写出本版本的事务编号        self.value = value        # 版本内容        self.roll_prev = None     # 回滚指针, 指向上一个旧版本  class Row:    def __init__(self, trx_id, value):        self.head = Version(trx_id, value)  # 链头永远是最新版本     def add_version(self, trx_id, value):        v = Version(trx_id, value)        v.roll_prev = self.head        self.head = v  class ReadView:    def __init__(self, active_ids, max_trx_id):        self.m_ids = set(active_ids)        self.min_trx_id = min(self.m_ids) if self.m_ids else max_trx_id        self.max_trx_id = max_trx_id     def is_visible(self, trx_id):        if trx_id < self.min_trx_id:            return True        if trx_id in self.m_ids:            return False        if trx_id >= self.max_trx_id:            return False        return True  class MVCCStore:    def __init__(self):        self.rows = {}        self.global_trx = 0        self.active = set()        self.views = {}  # trx_id -> ReadView, 实现可重复读     def begin(self):        self.global_trx += 1        self.active.add(self.global_trx)        return self.global_trx     def commit(self, trx_id):        self.active.discard(trx_id)        self.views.pop(trx_id, None)     def write(self, key, trx_id, value):        if key not in self.rows:            self.rows[key] = Row(trx_id, value)        else:            self.rows[key].add_version(trx_id, value)     def read(self, key, trx_id):        if trx_id not in self.views:            # 首次快照读才生成 ReadView, 之后复用(可重复读)            self.views[trx_id] = ReadView(set(self.active), self.global_trx + 1)        rv = self.views[trx_id]        cur = self.rows[key].head        while cur:            if cur.trx_id == trx_id or rv.is_visible(cur.trx_id):                return cur.value            cur = cur.roll_prev        return None     def purge(self):        removed = 0        for row in self.rows.values():            cur = row.head            while cur and cur.roll_prev:                prev = cur.roll_prev                needed = False                for rv in self.views.values():                    if rv.is_visible(prev.trx_id):                        needed = True                        break                if not needed and prev.trx_id not in self.active:                    cur.roll_prev = prev.roll_prev                    removed += 1                else:                    cur = prev        return removed  if __name__ == "__main__":    db = MVCCStore()     t1 = db.begin()    db.write("book", t1, "英文原版")    db.commit(t1)     t2 = db.begin()    db.write("book", t2, "中文新版")    t3 = db.begin()    print("t3 首次读取:", db.read("book", t3))   # 看不到未提交的新版    db.commit(t2)    print("t3 再次读取:", db.read("book", t3))   # 快照复用, 仍读旧版    print("t3 存续期回收:", db.purge())           # 旧版仍被快照引用    db.commit(t3)    print("全部提交后回收:", db.purge())          # 旧版可被回收

1. self.views[trx_id] = ReadView(set(self.active), self.global_trx + 1)首次快照读才生成借阅凭证，活跃事务集合必须拷贝副本，防止后续提交影响旧凭证
2. if cur.trx_id == trx_id or rv.is_visible(cur.trx_id):自己写的版本直接可见，否则按 ReadView 规则沿版本链判定
3. if trx_id < self.min_trx_id:小于最早活跃编号的版本为快照前已提交旧版，直接可见（绿色路径）
4. for rv in self.views.values():回收前遍历所有存活快照，确认没有凭证还在引用该版本
5. cur.roll_prev = prev.roll_prev断开待回收版本，完成链表摘除，物理空间得以释放
6. self.views.pop(trx_id, None)事务提交后删除其快照，释放引用，为后续回收让路
7. self.m_ids = set(active_ids)活跃事务名单快照化，避免外部集合变化污染判定结果

常见误区

面试题