企业官网建设流程全解析

数据库事务的隔离级别，几乎是后端开发里最容易被“背下来”却又最容易被“误解”的概念。我见过太多团队在面试时能把四种隔离级别倒背如流，结果一到线上就踩坑。比如某次排查一个对账系统数据跳变的问题，开发同学信誓旦旦说“我们用的读已提交，不可能读到脏数据”，但真相是他对隔离级别的理解只停留在“能不能防脏读”这个层面，完全没搞懂背后的锁和版本链机制。

这篇文章不打算给你再画一张“四个隔离级别防不防三种异常”的表格就完事。我想把这几件事讲透：隔离级别到底隔离了什么、数据库是用什么物理手段实现的、四种级别各自的加锁范围和漏掉的边界、以及为什么同一个“可重复读”在MySQL和PostgreSQL里根本不是一回事。最后配上几个我实际经历过的线上事故，看完你大概就能明白，选错隔离级别会引发什么样的连锁反应。

1. 隔离级别的本质：并发事务之间谁该看到谁的数据

先回到最原始的问题：为什么需要隔离级别？因为数据库要允许很多事务同时跑，但又不能让它们互相把数据搅成一锅粥。完全不加控制的话，两个事务同时改同一行数据，最后一个提交的会把前面那个覆盖掉；一个事务读数据时另一个事务正在改，读到的可能是改了一半的中间状态。这些乱七八糟的情况，就是数据库说的“并发异常”。

隔离级别做的事情，说白了就是给“谁能在什么时候看到什么数据”划一道线。这条线画得越严格，数据越可靠，但并发能力也越差；画得越宽松，系统越顺畅，但出错的概率越大。所以它不是数据库的“安全等级”，而是一个取舍旋钮。

1.1 没有隔离会出现的三种异常

这一块我建议不要死记定义，而是记住三个业务场景，因为你在线上遇到的每一个诡异问题，追根溯源基本都能归到这三类里。

脏读：事务A修改了一行数据还没提交，事务B就读到了这行“改了一半”的数据，然后A回滚了。B拿到的这个数据在数据库里从来就没有真正存在过，相当于你看同事写的草稿，他最后把整页撕了，但你已经在按草稿上的内容去办事了。脏读最典型的危害是决策错误——比如运营看到库存剩10件就上架了活动，实际上那个“10”是别人改了又回滚的假数据。

不可重复读：事务A在同一个事务里两次执行相同的查询，读到的结果不一样。原因是有别的事务在那期间提交了对某一行数据的UPDATE。注意这里的关键词是“UPDATE”，改的是某几行已经存在的值。类比一下：你在饭桌上听朋友说A同事月薪两万，过了十分钟又听他说A同事月薪两万五，中间他改了口。同一个人同一句话，你听了两个版本。

幻读：事务A两次执行同一个查询，第二次查询返回了第一次没见过的行。原因是别的事务在那期间插入了新行（INSERT）。它和不可重复读的区别非常关键：不可重复读是“同一行内容变了”，幻读是“凭空多出来一行”。为什么叫“幻”？因为你感觉像见了鬼，明明第一次查没有这行数据，第二次就冒出来了，而这行数据不是你自己插的。

1.2 隔离级别的定义：用异常反推出来的标准

ANSI SQL标准之所以定义了四种隔离级别，就是给数据库厂商一个明确的目标：你只要保证某一种级别下不发生某几种异常就行。

• 读未提交：允许脏读，什么都防不住
• 读已提交：防止脏读，但可能不可重复读和幻读
• 可重复读：防止脏读和不可重复读，但可能幻读
• 串行化：什么都防，事务之间完全排队执行

这套标准是1980年代定下来的，它有一个很大的问题——它只定义了“什么异常不能发生”，没有规定“用什么手段去实现”。这就导致不同数据库对同一个隔离级别的实现方式完全不同，行为也千差万别。后面我会专门讲MySQL、PostgreSQL、Oracle各自是怎么处理的，保证颠覆很多人的认知。

2. 支撑隔离的两大物理手段：锁与MVCC版本链

理解了隔离级别是“划红线”之后，关键问题来了：数据库到底靠什么物理机制去实施这条线？答案是两套东西协同工作——锁和多版本并发控制（MVCC）。

2.1 锁：处理写写冲突的最朴素武器

最直觉的并发控制方式就是锁。读数据加共享锁，写数据加排他锁。共享锁之间兼容，共享锁和排他锁互斥，排他锁之间互斥。如果要实现串行化，就简单粗暴：所有读写都加锁，冲突就等。

但这么做有一个致命问题：读和写完全互斥，导致一个写事务在跑的时候，后面所有要读这个数据的查询全部卡住。在互联网这种读多写少的场景下，这是不可接受的。数据库性能再强也扛不住“一写全等”。所以锁必须做得更精细，不能只靠这一招。

2.2 MVCC：让读不阻塞写，写不阻塞读

于是有了MVCC。它的核心思路不是“挡住读”，而是“给读提供历史版本”。简单说，每一行数据在修改的时候，旧版本不会立刻被删掉，而是被保留在一个叫undo log的地方，形成一条版本链。新来的读操作，如果发现数据正在被别的事务修改，它不需要等待，直接去版本链上找一个“合适的老版本”来读。

我把这个机制类比成超市的货架：货架上摆着最新价格的商品（当前版本），但仓库里保留着前一天甚至前一个小时的价签（历史版本）。顾客结账时，系统会根据他是“哪个时间点进来的顾客”给他看对应时间点的价签，而不是看他结账瞬间货架上的价签。

在MySQL InnoDB里，每条记录的版本链大致长这样：

(trx_id=100, 余额=900) --> (trx_id=80, 余额=500) --> (trx_id=20, 余额=200)

每个版本都记录着“写下这个版本的事务ID”，以及通过DB_ROLL_PTR指针指向前一个版本。MVCC通过比较“当前事务的快照ID”和“版本上的事务ID”来判断这个版本对自己是否可见。

2.3 快照读和当前读：理解隔离级别的钥匙

MVCC引出了一个特别重要的区分——快照读和当前读。

普通的SELECT就是快照读，走MVCC，不加锁，读的是某个历史版本。而UPDATE、DELETE、SELECT ... FOR UPDATE这些操作是当前读，它们必须读到最新版本，并且对行加锁。为什么？因为你要去修改这行数据，如果读到一个旧版本，然后再拿旧值去覆盖新值，就会造成丢失更新。

这个区分如果不理解，后面讲可重复读的时候你一定会懵。因为很多人以为是“事务开始那一刻就固定了一个统一快照，整个事务都从这个快照里读”，但实际上是——快照读从快照读，当前读从最新版读。这两种读在同一个事务里混合使用时，就会出现一些反直觉的锁定问题。

3. 四种隔离级别逐层拆解：加锁范围、防住什么、漏掉什么

这一章是核心中的核心。我会把每种级别对应的加锁策略、可见性规则，以及它“漏掉”的边界异常讲清楚。请注意，这一章的描述以MySQL InnoDB的实现为主，后面再讲其他数据库的差异。

3.1 读未提交：不加读锁，脏读的温床

读未提交的实现非常简单：写数据时加行级排他锁，但读数据完全不加锁，直接读最新版本。这意味着如果一个事务改了某行还没提交，另一个事务的读操作能直接看到这个改动。

这套策略的并发性能确实是最好的，基本没有读写互斥。但它给我们带来的麻烦是：你读到的东西不一定是真的。A事务把订单状态从“待支付”改成“已支付”，B事务立刻读到“已支付”去做后续发货操作，结果A因为余额不足回滚了，B已经把货发出去了。

这里必须说一个很多人不知道的细节：主流数据库实际上几乎没有人在生产环境使用读未提交。Oracle和PostgreSQL压根不提供这个级别的完整实现，MySQL虽然有但绝大多数团队也不会用。原因很简单：你省下的是几个读锁的代价，换来的却是业务上不可控的脏读风险，这笔买卖不划算。

提示：如果你的系统真的需要“读未提交”的性能，大概率是数据库设计出了问题，比如把热点数据放进了关系库里反复查询，更合理的方案是缓存或异步队列。

3.2 读已提交：解决脏读，但每句话都是新快照

读已提交是很多数据库的默认级别（后面会讲为什么MySQL偏偏不是）。它的实现规则是：

• 写数据加排他锁，防止其他写事务同时改同一行
• 读数据不加锁，但通过MVCC读取时，只能看到“已经提交”的版本

具体到MVCC机制上，读已提交的规则是：每条SELECT语句都会生成一个新的快照。所以第一条SELECT和第二条SELECT如果中间有别的事务提交了数据，这两个快照的内容就不同——这正好导致了不可重复读。

举个例子，假设账户余额是1000，事务A先查一次余额是1000，然后事务B给账户转入200并提交，事务A再查一次余额变成了1200。A的事务还没结束，同一个查询前后返回不同结果。这就是典型的不可重复读。

读已提交解决的是“别读到没提交的脏数据”，但它不保证“一个事务内前后读取一致”。如果你的业务场景是同一个事务里多次读取同一份数据做逻辑判断，读已提交会让你翻车。

3.3 可重复读：事务级快照，以及一个巨大的例外

可重复读在MVCC上的实现和读已提交有一个本质区别：快照的生成时机从“每条语句”变成了“事务内第一条语句”。也就是说，事务A一旦执行了第一条SELECT，它就拿到了一个固定快照，整个事务期间所有普通的SELECT都从这一个快照里读，与别人是否提交无关。

所以事务A第一次查余额是1000，不管事务B转入了多少钱，A之后再查余额永远都是1000，直到A自己结束。这就能保证“同一事务内多次读取完全一致”——不可重复读被防住了。

但幻读呢？标准的可重复读定义里，幻读仍然可能发生，因为MVCC的快照能防住“看到新插入的行”，却防不住“当前读”撞上别的事务新插入的行。

这里就牵扯到MySQL的一个特殊设计。如果你在可重复读下执行这样一组操作：

-- 事务A SELECT * FROM orders WHERE status = 'pending'; -- 返回2条 -- 事务B此时插入一条 status='pending' 的新订单并提交 SELECT * FROM orders WHERE status = 'pending'; -- 快照读：仍然返回2条（防住了幻读） UPDATE orders SET status = 'processing' WHERE status = 'pending'; -- 当前读：会把3条都锁住并更新

看到了吗？快照读防住了幻读，但UPDATE这种当前读依然会把新插入的那条数据包含进去。这就是为什么MySQL的InnoDB在可重复读下，还必须额外引入间隙锁（gap lock）来处理“当前读的幻读问题”。

间隙锁的作用是：当事务以某个条件范围加锁时，它不仅锁定存在的记录，还锁定记录之间的“空隙”，从而阻止别的事务往这个空隙里插入新行。比如上面的例子，如果事务A在SELECT ... FOR UPDATE时通过间隙锁锁住了status='pending'的区间，事务B想插入新的pending订单就会被阻塞，直到A提交。

所以MySQL InnoDB在可重复读级别下，用“MVCC防快照读的幻读”加上“间隙锁防当前读的幻读”，实际上把幻读也一并解决了。这也是为什么很多人说“MySQL的可重复读其实是安了扩音器的标准可重复读”——它比标准定义更强。

注意：“可重复读”三个字只保证“读”的一致，不保证“写”的一致。两个事务同时读到同一个版本的数据，然后基于这个旧值去做更新，后提交的会覆盖先提交的，这叫丢失更新。可重复读下依然可能发生，务必要记住这一点。

3.4 串行化：代价最高，却是唯一真正的“安全岛”

串行化实现起来最简单粗暴：所有事务完全排队执行。读加共享锁，写加排他锁，所有锁都持到事务结束。事务之间几乎不存在并发执行，自然也不存在脏读、不可重复读、幻读中的任何一种。

它和前面三种级别的本质区别是：前面三种是“并发控制”，串行化是“并发杜绝”。你可能会觉得“既然串行化这么安全，那就都用它呗”。现实是，绝大多数业务系统扛不住串行化的并发吞吐量。一个商品详情页一分钟几千个读请求，如果每个读请求都要排队等一个写请求把行锁释放，用户体验基本就废了。

串行化的适用场景是那些“宁可慢也不能错”的极少数核心路径，比如账户余额变动、优惠券发放中的强一致性校验。但即便如此，我也建议优先思考能不能通过分布式锁、幂等表、数据库约束等更廉价的手段达到同样的安全性，而不是一上来就无脑切串行化。

四种级别放一起看，会特别直观：

4. 同一个“可重复读”，在各大数据库里根本不是一回事

我在第一节就说了，SQL标准只规定了“不能有什么异常”，没规定“怎么实现”。这一章专门讲讲不同数据库的差异化实现，因为这是很多人在实际工作中踩坑的重灾区——你把在MySQL上学到的隔离级别知识，直接套到PostgreSQL上，可能会发现自己对“可重复读”的理解全是错的。

4.1 各家数据库的默认级别先看清楚

先来一张默认隔离级别的对照表，很多刚换数据库的团队第一次出问题，就是因为没意识到默认值变了。

MySQL的默认级别是高人一等的，偏偏它的使用群体还特别大，这导致很多开发者的知识体系以“可重复读”为默认参照系。但如果你去用PostgreSQL或Oracle，默认就是读已提交，事务内多次SELECT的结果可能不一样，这是完全正常且被设计的行为。

4.2 MySQL为什么死守可重复读

MySQL InnoDB默认是可重复读，很多人以为这是性能考量，其实很大一部分是历史包袱。在早期主从复制依赖基于语句的binlog时，如果主库用读已提交，一个事务里前后两条UPDATE语句作用于不同的快照，从库按照语句逐条重放，结果和主库事务级执行的效果可能不一致。可重复读能保证一个事务里所有语句看到的快照是一致的，这样基于语句的复制语义才可靠。

虽然现在基于行的binlog已经是主流，但由于兼容性考虑和大量现有的工具链，MySQL还是维持了可重复读作为默认级别。这也直接导致了一个现象：MySQL用户普遍对Read Committed的同义语义不熟悉，一换到别家数据库就打起架来。

4.3 PostgreSQL的“快照隔离”比MySQL强在哪、弱在哪

PostgreSQL的可重复读实现非常干净：它使用SSI（Serializable Snapshot Isolation）的变体，完全基于快照，不使用间隙锁。这意味着在PostgreSQL的可重复读下，普通的快照读天然免疫幻读——因为整个事务都在同一个快照里看数据。

但PostgreSQL的可重复读有一个很多人不知道的边界问题：它仍然允许一种叫“写偏斜”的异常。举个经典例子，两个人同时登录一个值班系统，系统规则是“必须至少有一个人值班”。事务A查一下当前值班人数（看到A和B都在值班），准备把A改成不在值班；事务B也查一下当前值班人数（看到A和B都在值班），准备把B改成不在值班。两个事务都基于“当前有两人值班”这个前提，各自去更新自己的那条记录，最后系统里值班人数变成0——这就是写偏斜。

MySQL的可重复读同样存在写偏斜的可能，因为MVCC的隔离机制管不住两个事务各自修改不同行的交错写入。从这一点上说，“可重复读”不等于“可串行化”。只有真正的串行化级别才能防住写偏斜。

4.4 Oracle的特殊性：只有两个隔离级别可用

Oracle的设计哲学更激进：它干脆没给你读未提交和可重复读的完整实现，实际业务里就是在读已提交和串行化之间二选一。而且Oracle的“串行化”也不是真正的串行执行，而是基于回滚段的快照隔离，名字叫Serializable实际上还是乐观并发。

所以如果你从Oracle切换到PostgreSQL，会发现两者在读已提交下行为很接近；但如果从MySQL切到Oracle，你要特别注意SQL里每条语句的执行语义和默认隔离级别的差异，尤其是锁等待超时和死锁的处理方式完全不在一个套路。

5. 生产环境里到底怎么选：判断维度与组合建议

讲清楚原理之后，聊聊实战。很多人问：“我到底应该把隔离级别设成什么？”我给不了你一个能通吃的答案，但可以给你一套决策框架，你按着这个思路去判断，方向不会错。

5.1 三个关键判断维度

第一个维度：业务对数据一致性的容忍度。财务账单、库存扣减、优惠券发放，这属于“差一分钱都是事故”的场景，隔离级别必须保守；而文章阅读数、商品浏览量、帖子点赞数，这属于“差几个数看不出问题”的场景，完全没必要为了所谓的安全牺牲性能和扩展性。

第二个维度：单行数据的写冲突概率。如果某个热点行（比如爆款库存只剩10件）经常被并发更新，可重复读下间隙锁反而可能引发连锁等待甚至死锁，这时候宁可退到读已提交配合乐观锁重试。反过来，如果写冲突概率很低，用可重复读可以保证出报表时的一致性读，减少不少麻烦。

第三个维度：事务的时长和范围。长事务（比如跑批任务、清洗数据）在可重复读下会持有大量间隙锁，对全表插入都有阻塞作用，实际上拉低了全库的并发。这种场景应该想办法把大事务拆成多条小事务，而不是靠隔离级别硬扛。

5.2 不同业务的实用组合参考

我不写那种“这是最优解”的话，只分享我自己的习惯组合，你在生产环境里可以拿去做基准参考：

MySQL场景：常规互联网业务直接用默认的可重复读，不折腾；秒杀、库存扣减这种高并发写热点，我建议把事务改短、用读已提交或者干脆走Redis队列预扣减，数据库侧只做最终校验；对账类报表、需要在整个事务里保持视角稳定不变的，继续保持可重复读最省心。

PostgreSQL场景：默认读已提交完全可以应付90%的业务；需要事务内一致读取的，显式开启可重复读；那些定时任务里需要一致的快照做数据导出的，用可重复读来跑是最舒服的，不像MySQL还要担心间隙锁。

Oracle场景：普通业务用读已提交；涉及强一致性和资金类的关键路径，加悲观锁或用串行化，注意评估死锁概率和性能损失。

我强烈建议在所有项目中加一层逻辑层的重试和幂等。无论选哪个隔离级别，都必然有锁冲突的时候，别指望数据库把所有并发问题都挡在门外。框架层面支持乐观锁版本号、请求幂等键、失败重试，这三件套比单靠优化隔离级别靠谱一万倍。

5.3 关于“调整隔离级别”最常见的误区

我见过团队把隔离级别从可重复读改成读已提交之后，代码没有任何改动，结果一周后突然出现“同一笔订单被重复支付”的线上事故。根因是代码里大量用了“先SELECT再UPDATE”的天然乐观锁思路，在可重复读下，事务内多次SELECT一致，所以逻辑判断还靠得住；切到读已提交之后，SELECT之间别人可能已经把数据改了，后面的UPDATE直接把别人提交的数据覆盖掉，丢失更新。

所以每当你想要调整隔离级别，一定要先审一遍代码里所有“读取-判断-更新”的链路，明确哪些依赖了事务内快照的一致性。调整隔离级别不是改个配置那么轻松，它其实是整个并发模型的切换。

6. 真实事故复盘：隔离级别选错之后的连锁反应

这一章是白送你的避坑手册。我把这些年遇到的和听说过的几类事故整理出来，每个都给出现象、根因和修复思路，保证你在排除线上问题时能按图索骥。

6.1 事故一：读已提交事务中两次查询，报表数字前后矛盾

某电商团队的运营后台有个“实时销售统计”页面，页面上显示“今日订单金额”和“今日订单数”。这个统计是同一个事务里两条SQL查询出来的。在可重复读下一切正常，后来某天有人把连接串的隔离级别改成了读已提交，第二天运营反馈：订单数和订单金额对不上，金额比订单数算出来的平均值高出一大截。

排查后发现：两条SELECT分别生成了两个快照，中间恰好有大量新订单提交进来，导致第一条查到的订单数和第二条查到的金额不是同一批数据。修复方案有两个方向：把统计数据放在一条SQL里用子查询一次查出，或者保持可重复读让整个事务共享一个快照。后来我们直接把那段逻辑抽成了独立的只读连接，专门走可重复读，报表再也不飘了。

这个事故告诉我：隔离级别在任何数据库里都不是“选一个高级的就完事”，需要根据每条业务SQL的读取模式来配套设计。

6.2 事故二：可重复读下的“读后写”仍然把更新弄丢了

这个案例特别有代表性。某支付系统的退款接口逻辑大概是：先查订单余额，判断可退金额，然后执行UPDATE扣减余额。数据库用的是MySQL可重复读。正常情况没问题，但某次活动期间大量退款请求并发涌入，出现了多笔退款金额之和超过订单原金额的情况。

根因是：两个退款事务都通过快照读到了同一个“可退余额=100”，都认为可以退100，然后各自执行UPDATE。可重复读的快照读取不保证当前读的可见性，两个UPDATE都读到最新版本时，谁后提交谁覆盖对方——第一个UPDATE把余额变成0，第二个UPDATE读到余额还是100，再扣100，余额变成-100。典型的丢失更新。

修复思路有三层可选：第一层，给订单余额行加悲观锁，SELECT ... FOR UPDATE，让并发退款排队；第二层，用乐观锁版本号，UPDATE时带上version条件；第三层，把“可退金额”的校验挪到数据库约束层（比如CHECK余额不小于0），从源头卡死。我当时用的是悲观锁，因为它最直观，逻辑改动最小。

6.3 事故三：可重复读间隙锁酿成的连环死锁

另一个案例是某OTA系统的酒店库存接口。这个接口的业务逻辑是：查询某日期段内所有房型的库存，然后选择最优的价格组合下单。在可重复读下，查询用了SELECT ... FOR UPDATE锁定了整段日期的库存记录区间。两个用户同时操作同一家酒店不同房型时，A锁了日期1-3的房型A，B锁了日期2-4的房型B，然后A要去锁房型B的区间，B要锁房型A的区间，死锁就发生了。

这个事故最大的教训是：间隙锁虽然解决了幻读，却带来了额外的死锁半径。排查时用SHOW ENGINE INNODB STATUS直接看到了两个事务互相持有对方需要的间隙锁，死锁链路一目了然。修复方案是缩小加锁范围，把业务逻辑从“一次性锁住整个日期区间”改成“逐行按需锁定”，同时开启事务前先按固定顺序排序访问的资源，避免互相等待。

6.4 事故四：连接池复用把“伪长事务”带到了生产环境

这个和隔离级别看似无关，实际关系极大。某团队的代码里有个方法，JDBC连接设置了setAutoCommit(false)，处理完业务逻辑后忘了commit，直接把连接还给了连接池。隔离级别虽然还是默认的可重复读，但事务边界被无限放大——这条物理连接上跑的下一个请求，莫名其妙就继承了上一个未提交事务的快照和所有锁。

于是全团队排查了很久的“奇怪锁等待”问题，最后靠查询数据库里的长事务列表（information_schema.innodb_trx）才定位到。这个教训值得所有团队重视：隔离级别的正确设置必须建立在正确的事务边界管理之上。你配得再对，事务边界打开不关闭也一样会出事。建议在框架层面统一管理事务的提交和回滚，并开启数据库侧的慢事务告警。

6.5 事故五：PostgreSQL默认读已提交下的促销超卖

某社区电商系统迁移到PostgreSQL后，把默认连接串的隔离级别设成了读已提交，此前在MySQL可重复读下一直没出问题的“限时抢购”逻辑，上线三天就出现了超卖。

原因依然是丢失更新——两个事务都读到剩余库存为1，分别执行扣减，PostgreSQL读已提交下两个事务互不可见，后提交的覆盖先提交的，最后库存变成-1。修复时没有无脑改回可重复读，而是让库存扣减SQL变成原子操作：UPDATE inventory SET stock = stock - 1 WHERE id = ? AND stock >= 1，把判断下推到数据库，并检查受影响行数。这种方式既高效又不受隔离级别影响，比靠锁和事务边界硬扛简单太多。

排除这类问题的通用思路是：先看是不是丢失更新（现象是数据被覆盖），再看是不是脏读或不可重复读（现象是数据跳动），最后看是不是死锁（现象是锁等待超时）。选对方向，排查速度快很多。

最后说一点个人体会。我见过太多团队把“数据库怎么选”当成一个配置问题去处理，实际上隔离级别是并发模型的核心组件，它决定了你的业务逻辑在极端情况下还保不保得住正确性。我的建议是：在自己的项目里，针对每种隔离级别写一个小的并发测试用例，把脏读、不可重复读、幻读、丢失更新这些场景全部跑一遍，亲眼看看数据库的表现，再结合业务场景去定默认值。一次测试省下来的排查时间，远比你背下所有手册里的定义值钱得多。