SQL事务隔离机制：并发访问不互相干扰的秘密

可视化演示

可视化展示四种隔离级别（RU/RC/RR/SR）对脏读、不可重复读、幻读的防护能力，直观对比MVCC多版本并发控制机制。

并发问题背景

合租公寓的厨房之所以能运转，靠的是一本《公寓管理规约》。规约规定了四条底线：做饭必须一气呵成，不能做一半就丢下不管；做出来的菜必须靠谱，不能把厨房搞成一锅乱炖；每个人用厨房时不能随意干扰别人；今天分配好的食材，明天依然有效。这四条底线，正是数据库事务ACID四大特性的生活版。

在数据库里，ACID分别指原子性（Atomicity，事务不可分割地全部成功或全部失败）、一致性（Consistency，事务前后数据始终合法）、隔离性（Isolation，并发事务之间互不干扰）、持久性（Durability，事务提交后数据不丢失）。四者之中，隔离性最难实现：因为多个事务真的会同一时刻发生。如果没有隔离，就会出现三类典型的“厨房事故”：脏读、不可重复读、幻读。下文讲的四个隔离级别，就是针对这三类事故的不同防范等级。

明确了规约底线和事故清单，我们就能为四套“厨房使用规范”打分：哪套规范能防住哪些事故，一目了然。

读未提交

若合租厨房采取“完全自由”模式，大家想怎么用就怎么用。小李正在炒菜，夹起一块肉尝了尝，觉得太咸，可能下一秒就重新做。可小王站得近，已经看到了那块肉的颜色和摆盘，把它当成了小李的招牌菜配方记在心里。更糟的是，小李最后觉得不好吃，把肉整个倒掉了，小王却还惦记着那块“从未存在于餐桌”的肉——他读到了一份凭空想象出来的数据。这就是脏读。

在SQL世界里，读未提交（READ UNCOMMITTED）是最低隔离级别。事务可以读取其他事务尚未提交的数据，如果那个事务随后回滚，本事务读到的就是彻底作废的脏数据。这个级别几乎不加任何锁或版本控制，并发性能最好，但数据一致性最差，现实中极少被采用，除非业务对数据正确性毫不在乎（比如纯日志采集、无脑统计大数）。

读未提交就像没有门锁的厨房，谁都能探头看你锅里的半成品——哪怕那盘菜可能下一秒就被倒掉。生产环境几乎见不到它的身影，但它作为“警示底线”，让我们清楚知道不设防的世界有多混乱。

读已提交

室友们痛定思痛，投票通过新规约：“厨房里发生的一切，只有端上桌的菜才算数。”小李在灶台上煎牛排，加了多少次黄油、尝了几回咸淡，只要他没把牛排端上桌，小王就绝不会把它当成一道成菜。这样，脏读被成功杜绝。但新问题随之而来：小王做咖喱时，第一勺尝咸淡用的是旧盐罐，第二勺时小李恰好换了新盐罐。同一锅咖喱，两次尝出两种咸度——这就是不可重复读。

读已提交（READ COMMITTED）保证事务只能读到已经提交的数据，每次读取都获取当前最新的已提交值。它有效避免了脏读，但两个独立的SELECT之间，如果其他事务提交了修改，本事务前后就会读到不同的值。正因它在正确性与并发度之间取得了良好平衡，Oracle、PostgreSQL等数据库都把它设为默认隔离级别。

读已提交像一家“上桌才算菜”的餐厅后厨：你不会看到别人没端上桌的食材，却没法保证自己锅里两次调味的味道永远相同。对大多数业务来说，这个级别已经足够日常使用。

可重复读

室友们又被不可重复读折磨得不轻，于是引入更聪明的制度：每个厨师进厨房的瞬间，管理员给他拍一张“厨房全景照片”作为快照。小王拿着照片，不管别人往冰箱里塞了什么、换了哪罐盐，他做菜时只认照片里的样子。两次尝盐，一定尝到同一罐盐——不可重复读被根治了。但如果小张在照片之外偷偷往菜单上加了一道“隐藏菜”，小王按照片对菜单，从头到尾都不知道这道菜的存在，直到做完饭对账才惊讶地发现：咦，怎么凭空多出一道菜？这就是幻读。

可重复读（REPEATABLE READ）是MySQL InnoDB的默认隔离级别。它通过MVCC在事务开始时生成一致性快照，事务内所有普通SELECT都基于该快照读取，因此前后读必然一致。但按SQL标准，其他事务新插入的行不会被本事务快照涵盖，因此幻读仍然可能发生。需要说明的是，MySQL InnoDB在可重复读下通过间隙锁（next-key lock）额外压制了大部分幻读，这是它对标准的一种增强——但这属于数据库实现层面的“加餐”，并非标准默认承诺。

可重复读就像给每个厨师发了一张入场快照：照片里的世界永远稳定，只是照片外的世界仍在悄悄生长。它非常适合对报表一致性有要求的读多写少场景。

串行化

最极端的规约来了：厨房门口挂上一把大铁锁，一次只放一个人进去做饭。小王用完了、菜端出来了、厨房收拾干净了，下一个小李才能进去。这样的世界绝对不会有任何干扰——你看到的、用到的、做成的一切，都是你独占厨房的成果。代价也惨痛：晚饭高峰期六个人排队，等最后一个人吃上饭，已经深夜了。

串行化（SERIALIZABLE）是最高隔离级别。事务逐个执行，最终效果等价于串行调度，彻底避免脏读、不可重复读、幻读。数据库通过加锁（表锁、区间锁）或冲突检测实现。它的一致性最强，但并发性能断崖式下降：锁等待、阻塞、超时频繁，吞吐量远低于其他级别。只有在正确性要求极高且并发量不大的场景——比如资金结算、账务对账、库存清点——才会选用。

串行化是“一个厨房一把锁”的终极方案：安全满分，效率垫底。它提醒我们，隔离级别不是越高越好，而是刚刚好才好——用最合适的成本换取业务可接受的一致性。

MVCC原理

可重复读的“入场快照”究竟是怎么实现的？总不能让数据库真的给每个厨师打印一张实体照片吧！MVCC的答案是：数据库为每行数据保存多个版本，就像冰箱里同一食材的多个“进货批次”。每个事务被分配一个专属的“食材视图”，你看到的不是冰箱的最新状态，而是进入厨房那一刻的食材批次。每份食材都贴着标签：是哪个事务放进来的（trx_id），它之前的版本在哪里（roll_pointer）。

MVCC（Multi-Version Concurrency Control，多版本并发控制）是现代数据库的主流实现。每个数据行都有隐藏字段：DB_TRX_ID记录最近修改该行的事务ID，DB_ROLL_PTR指向undo log中旧版本的回滚指针。旧版本通过undo log串成一条版本链。事务读取时，沿版本链找到对当前事务可见的版本。可见性规则的核心是：版本必须由已提交且早于快照创建的事务产生，或者干脆就是当前事务自己写的。这样，读操作不加锁，写操作也不阻塞普通读，读写在MVCC下可以并行，极大提升并发度。

MVCC就是“多批次食材+专属视图”的数据库工程化实现。它让快照读与写入并行不悖，是读已提交和可重复读高效落地的幕后功臣，也是高并发系统能跑得又快又稳的秘密武器。

级别选择

四套厨房规约没有绝对优劣，只看你们的公寓是什么氛围。全是自己人、做饭随意尝——读未提交；有客人来访、至少要讲究“上桌才算菜”——读已提交；你们要开一家对外营业的私房菜馆、每道菜的口味必须前后一致——可重复读；做的若是手术室级别的营养配餐、一丝差错都不能有——串行化。规矩越严，心里越踏实，但大家做饭的速度也越慢。

实际工程中，隔离级别选择本质是正确性与性能的权衡。级别越高，锁越多，性能越差。主流数据库默认值各异：MySQL InnoDB默认REPEATABLE READ，配合MVCC和间隙锁，实际防护已接近串行化；PostgreSQL、Oracle、SQL Server默认READ COMMITTED。报表分析、订单查询等读多写少场景，可重复读的快照保证报表前后口径一致；高并发写入的核心交易链路，读已提交往往能在不损失必要一致性的同时给出最佳吞吐；资金对账等强一致场景才考虑串行化。

选隔离级别，本质是给公寓选“厨房规约”：既要吃得放心，又不能让室友们饿肚子。经验丰富的DBA会在正确性红线与业务吞吐之间，找到那条最舒适的平衡线。

实战排查

作为公寓管理员，你需要随时知道：现在执行的是哪套规约？哪间房的厨师在违规操作？出了问题去哪查记录？SQL世界也提供了一整套“管理工具”：查看当前的隔离级别、为会话切换隔离级别、诊断锁等待与死锁。

查看隔离级别，MySQL 8.0用SELECT @@transaction_isolation;，5.7用SELECT @@tx_isolation;；PostgreSQL用SHOW default_transaction_isolation;。设置隔离级别，执行SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;只影响当前会话，使用GLOBAL关键字则影响全局新连接。排查并发问题，SHOW ENGINE INNODB STATUS\G能查看锁与死锁信息，information_schema.innodb_trx能列出当前活跃事务及其持锁情况。

掌握了这套“管理员工具”，你就能在线上事故发生时快速判断：是哪个环节的规约出了漏洞，是脏读、不可重复读还是幻读，从而对症下药，让数据库恢复平稳运行。

AI 应用场景

Python 演示

class MiniMVCC:    """极简MVCC模拟器: 演示四种隔离级别下事务读到的数值差异"""     def __init__(self, initial=100):        self.base_value = initial        # 已提交的最新值        self.buffer_map = {}             # 未提交写入缓存        self.snapshot_map = {}           # 各事务的快照        self.version_list = []           # 已提交版本链        self._trx_counter = 0     def begin(self):        self._trx_counter += 1        return self._trx_counter     def write(self, trx_id, new_value):        self.buffer_map[trx_id] = new_value     def commit(self, trx_id):        value = self.buffer_map.pop(trx_id)        self.version_list.append((trx_id, value))        self.base_value = value     def rollback(self, trx_id):        self.buffer_map.pop(trx_id, None)     def read(self, trx_id, level):        pending = list(self.buffer_map.values())        if level == "读未提交":            return pending[-1] if pending else self.base_value        if level == "读已提交":            return self.base_value        if level == "可重复读":            return self.snapshot_of(trx_id)        return self.base_value       # 串行化: 等锁后读最新     def snapshot_of(self, trx_id):        if trx_id not in self.snapshot_map:            self.snapshot_map[trx_id] = self.base_value        return self.snapshot_map[trx_id]  if __name__ == "__main__":    db = MiniMVCC(initial=100)    t1 = db.begin()    t2 = db.begin()    db.write(t1, 500)                    # T1 将余额改为 500, 未提交    print("T1 未提交时 T2 读到的余额:")    for level in ["读未提交", "读已提交", "可重复读", "串行化"]:        print(f"  [{level}] -> {db.read(t2, level)}")    db.commit(t1)                        # T1 提交    print("T1 提交后 T2 读到的余额:")    for level in ["读未提交", "读已提交", "可重复读", "串行化"]:        print(f"  [{level}] -> {db.read(t2, level)}")

1. self.buffer_map = {}未提交写入缓存，对应“厨房里没端上桌的半成品”，脏读的源头。
2. self.snapshot_map = {}各事务的快照字典，可重复读的“入场照片”就存在这里。
3. def write(self, trx_id, new_value)把新值写入未提交缓存，模拟事务修改数据但还没提交。
4. def commit(self, trx_id)从缓存取出值写入版本链，已提交值更新，模拟“菜端上桌”。
5. if level == "读未提交"直接返回未提交缓存里的最新值，完整演示脏读路径。
6. return self.snapshot_of(trx_id)可重复读永远走快照，事务内读取结果前后一致。

常见误区

面试题