事务与MVCC：ACID特性

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

事务概念基础——一件事的完整仪式

室友阿明今晚要做鱼香肉丝，从开冰箱拿肉、切菜、开火、爆炒、上桌，到最后一并洗碗收拾，这是一套不能拆开的完整仪式。任何一步半途而废，这顿饭就不成立。数据库里，这个“完整仪式”就叫事务（Transaction）：把多条 SQL 语句打包成一个逻辑单元，要么一起成功，要么一起失败，不允许只成功半截。

为什么需要打包？最经典的例子是转账：从张三账户扣 100 元，同时给李四账户加 100 元。这两条 SQL 必须绑定在一起。如果只扣不加，钱就凭空消失了；只加不扣，银行就得破产。数据库用事务把“扣”和“加”焊成一块，谁也别想拆开。

在工程上，事务以 BEGIN 或 START TRANSACTION 开始，以 COMMIT（提交，确认结果永久生效）或 ROLLBACK（回滚，撤销全部操作）结束。它的一生有明确规定：执行中、执行完待提交、已提交；或执行中、失败、已回滚。MySQL 的 InnoDB 引擎会在执行每条写操作时顺手把旧值记入 undo 日志，为随时回滚做好准备。

事务的开端，就是阿明系上围裙的那一瞬间。数据库从此记住：这个人要么完整地做完一顿饭，要么把厨房恢复原样。

原子性原理——全有或全无的烟火

锅里已经开始冒烟，阿明发现酱油瓶是空的，油温又太高。他当机立断：这顿饭不做了。于是把肉放回冰箱、菜倒回袋里、锅刷干净、台面抹平——厨房恢复到开火之前的样子，仿佛一切都没发生过。这就是原子性（Atomicity）：全有或全无，不允许中间状态。

数据库里，原子性意味着一个事务中的所有操作被视为一个不可分割的整体。要么全部执行成功并留下结果，要么全部不执行，数据回到事务开始前的状态。绝不存在“转账扣了款，但入账失败”这种半吊子结果。它像一道闸门：整道工序不过关，就把闸门后面所有东西冲回原点。

支撑这道闸门的，是 undo 日志（撤销日志）。InnoDB 在每条写操作执行前，会把旧值记入 undo 日志，形成一条“逆操作链”。回滚时，数据库沿着这条链从后往前逐个执行逆操作：INSERT 的逆操作是 DELETE，UPDATE 的逆操作是恢复旧值，DELETE 的逆操作是重新插入。旧值链有多长，回滚就能走多远。

阿明凭着一张“撤销备忘清单”把厨房恢复原样。数据库的 undo 日志，就是那张清单——不是靠记忆，而是靠逐条记录的旧值，把烟火气一点点抹干净。

一致性保障——账目永不失衡

公寓公约里有一条硬规矩：公共冰箱里的东西必须账实相符。阿明拿走一瓶酱油，就得在记账板上写“借酱油一瓶”；用完放回来再划掉。如果谁拿了东西却不肯记账，月底一盘点，账就平不了。数据库的一致性（Consistency）讲的就是这个：无论事务怎么折腾，数据必须从一种合法状态变到另一种合法状态，不允许出现“负余额”这种荒谬账目。

这些合法性由两类规则定义：一类是数据库内置的完整性约束——主键不能重复、外键必须存在、字段不能有空值；另一类是业务规则——转账总量不变、库存不能为负、余额不能透支。前者数据库自动强制，后者写进应用逻辑。事务提交后，所有规则必须同时成立。

一致性不是某一个机制单独实现的，而是“原子性 + 隔离性 + 应用正确性”共同作用的结果。原子性保证中途失败不会留下残缺账目；隔离性保证其他事务看不到还没算完的中间账；而业务的正确逻辑保证约束本身被满足。四者合在一起，才凑齐了“账永远平”这一结果。它也解释了为什么一致性常被称作 ACID 中“最含糊”的一条——它更像一个目标，而不是一种具体机制。

账目守恒的公约，从来不是靠单独一条规矩生效的，而是所有规矩形成合力。一致性也一样——它是数据库约束与业务规则共同守卫的那杆秤。

隔离性级别——厨房的四扇门

公寓里常有两个人同时想做饭。为了避免互相泼油、抢灶台，你们设计了四种厨房使用模式，由紧到松：第一种全开放，谁都能进来随便看甚至用半成品，这叫读未提交；第二种半开放，能看到别人橱柜里最终的成品，但看不到还没做完的锅，这叫读已提交；第三种个人包间，关上门后你看到的一切自始至终不变，门外的动静与你无关，这叫可重复读；第四种严格排队，一人做完下一位再进，这叫串行化。

隔离性（Isolation）就是这个意思：多个并发事务各自看到的数据世界不能互相干扰。标准 SQL 定义了四个隔离级别，每个级别解决一些并发问题，又留下另一些问题。读未提交可能读到别人没提交的脏数据（脏读）；读已提交解决了脏读，但同一事务内两次查询结果可能不同（不可重复读）；可重复读保证事务内读到的数据始终一致，但另一个事务插入新行，导致查询多出数据（幻读）；串行化把一切并发都排成队，彻底消除异常，代价是吞吐量骤降。

MySQL InnoDB 默认使用可重复读，但它并非放任幻读不管——它靠 MVCC 快照读屏蔽了幻读的“读半边”，再用间隙锁（Gap Lock）管住“写半边”。也就是说，四个标准级别是通用分档，具体引擎可以在同一档位上做出更强的保证。

厨房选哪扇门，取决于今天是想快速做个简餐，还是想安静地招待客人。数据库选隔离级别，就是在“做菜效率”和“不被打扰”之间，挑一扇恰到好处的门。

持久性机制——永久流水账本

公寓有一次半夜跳闸，冰箱的凉气跑光，刚买的肉差点坏掉。好在你们有一本永不撕页的“永久流水账本”：谁在什么时间把什么食材放进冰箱，每一笔都记得清清楚楚。第二天照着账本，把食材挪进备用冷柜，损失被完全挽回。持久性（Durability）正是这本账本的意义——事务一旦提交，修改就永久保存，哪怕断电、崩溃，数据也绝不丢失。

数据库靠两条腿走路：一条是 undo（撤销），一条是 redo（重做）。redo 日志是物理日志，记录“数据文件中第几页、哪个偏移量、被写成了什么字节”，精确到细胞的病历。事务提交前，数据库先把这批 redo 记录落盘，再动数据页面本身——这就是传说中的 WAL（Write-Ahead Logging，预写日志）。先记账、后干活，账本永远比现场多一步。

如果提交后系统崩溃，但数据页还没来得及写进磁盘怎么办？崩溃恢复时，数据库扫描 redo 日志，把已提交但未落盘的操作重放一遍，就像对照账本把食材重新归位。因为“先写日志再写页”的顺序保证，日志里有的必然能恢复。redo 管“重做”，undo 管“撤销”，一个向前救火，一个向后灭火，方向正好相反，分工互不重叠。

厨房里最值钱的不是食材本身，而是那本怎么撕都撕不烂的流水账。数据库的 redo 日志也一样——只要账本还在，任何灾难都只是重做一遍的事。

MVCC多版本——各看各的历史快照

阿明和阿强同时在厨房做菜。阿明开火时看到冰箱里鸡肉剩 500 克，阿强晚五分钟开火，看到的也是那 500 克。两人各拿各的“进门快照”，互相不干扰。可阿明中途炖掉 100 克鸡肉，阿强并不知道，也不影响他按自己的快照做菜。这就是数据库的多版本并发控制（MVCC，Multi-Version Concurrency Control）——让每个事务活在属于自己的“厨房照片”里。

老派的做法是锁：读的时候锁住数据不让写，写的时候锁住数据不让读，读和写互相堵车。MVCC 换了个思路：同一行数据不只存一个当前值，而是通过 undo 日志保留一串历史版本。写操作生成新的“当前版本”，旧版本不删除，而是挂在一条版本链上；读操作去读某个合适的旧版本，压根不用等写操作完成。于是读不阻塞写，写不阻塞读，两条车道各自通行。

在 InnoDB 中，每行记录头都藏着两个隐藏列：trx_id（生成这个版本的事务 ID）和 roll_pointer（回滚指针，指向 undo 日志里的上一个版本）。所有版本通过 roll_pointer 串成一条完整的版本链，最新版本在链头，最古老的在链尾。不同事务根据自己的“快照”决定从链上取哪个版本。

版本链就是厨房里的整本“老照片档案”。想看清旧厨房的模样，翻出对应日期的照片就行，完全没必要把现在桌上的菜端走。MVCC 的智慧就在这三言两语之间。

可见性判断——按号码牌认账

阿明拿着进门时拍的快照，想知道“冰箱里的鸡肉到底应该看哪个版本”。光有快照不够，还得有一份号码牌名单：哪些室友在我进门时已经在厨房里忙活（事务还在活跃），哪些早就做完走了（事务已提交）。号码牌一对，该认账还是不该认账，一清二楚。

这份号码牌名单在数据库里叫 ReadView（读视图），它记录四个关键值：creator_trx_id（生成视图的事务 ID，即“我自己”）、min_trx_id（活跃事务中最小的 ID）、max_trx_id（下一个将被分配的事务 ID，即上界）、active_ids（当前所有活跃事务的 ID 集合）。拿到一个历史版本，看它的 trx_id 是谁生成的，再用下面的规则判断是否对当前事务可见：

ReadView 的生成时机决定了隔离级别的行为差异：读已提交（RC）每次 SELECT 都会生成新视图，所以两次查询可能看到不同的最新提交；可重复读（RR）只在事务第一次查询时生成一次视图，之后一直复用，所以整个事务看到的是同一个冻结的厨房。号码牌名单一旦定下，厨房的景象就凝固了。

工程权衡——完美公约的代价

如果把厨房四壁都加上防弹玻璃，每个室友完全隔离，安全是安全了，可谁都进不去做饭了。数据库也一样：隔离级别拉到串行化，并发全部排成队，吞吐量断崖式下跌。工程上从不存在“绝对安全”的免费午餐，只有“够用即可”的取舍。

MVCC 也不是万能药。它解决的是读与写之间的冲突，让两边互不阻塞；但两个事务同时改写同一行，写与写之间的冲突仍然存在，绕不开锁或版本号。更隐蔽的是快照隔离下的丢失更新：两个事务都基于同一旧快照读到了库存 100，各自减 1，先后提交，结果库存变成 99 而不是 98——其中一个更新被静默吞掉了。

所以工程师的真实工作，是学会选门和补漏：读多写少的长查询业务，用可重复读 + MVCC 性价比最高；金融转账、库存扣减这类强一致场景，就要上显式锁、乐观锁甚至串行化。给公寓选门的智慧，从来都是“刚刚好”，而不是“最安全”。

AI 应用场景

Python 演示

class SimpleTxnDB:    def __init__(self):        self.data = {}          # 数据表: key -> value        self.undo_log = []      # 撤销日志: [(key, old_value)]     def set(self, key, value):        old = self.data.get(key)        self.undo_log.append((key, old))        self.data[key] = value        print("SET {} = {} | undo_log_len = {}".format(key, value, len(self.undo_log)))     def rollback(self):        while self.undo_log:            key, old = self.undo_log.pop()            if old is None:                self.data.pop(key, None)            else:                self.data[key] = old        print("rollback done, data = {}".format(self.data))     def commit(self):        self.undo_log.clear()        print("commit done")  def mvc_visible(trx_id, min_id, max_id, active_ids, creator_id):    if trx_id < min_id:        return True    if trx_id >= max_id:        return False    if trx_id not in active_ids:        return True    return trx_id == creator_id  if __name__ == "__main__":    db = SimpleTxnDB()    db.set("alice", 100)    db.set("bob", 0)    db.set("alice", 70)    db.set("bob", 30)    db.rollback()    assert db.data == {}, "atomicity: all changes undone"     assert mvc_visible(1, 2, 5, [2, 3], 4) is True   # t < min_id    assert mvc_visible(4, 2, 5, [2, 3], 4) is True   # t == creator    assert mvc_visible(3, 2, 5, [2, 3], 4) is False  # t in active_ids    assert mvc_visible(5, 2, 5, [2, 3], 4) is False  # t >= max_id    print("MVCC visibility rules passed")

1. self.undo_log.append((key, old))每次写之前先把旧值存入撤销日志，这是“先记账后干活”。
2. while self.undo_log:从日志尾部开始逐个弹出，执行逆操作恢复旧值。
3. if old is None: ... else:旧值为空表示原本没有该键，回滚时删除；否则恢复原值。
4. db.rollback()一次回滚把四次 set 全部撤销，assert db.data == {} 验证原子性。
5. mvc_visible(1, 2, 5, [2, 3], 4)用具体数字验证可见性规则的四条分支：小于最小ID可见、自己是创建者可见、活跃列表不可见、大于上界不可见。

常见误区

面试题