MySQL默认隔离级别REPEATABLE READ深度解析：InnoDB事务机制与MVCC原理

我面试后端候选人时经常用一个问题开场MySQL 默认的事务隔离级别是什么能答出 REPEATABLE READ 的人不少但再追问一句为什么 InnoDB 选它做默认值而不是 Oracle 常用的 READ COMMITTED大半人就卡住了。有人开始背 MVCC有人张嘴就是锁但讲到同一事务内多次读取结果必须稳定这个工程诉求以及主从复制和 binlog 格式这条历史线索基本就没人能接下去了。这篇文章我想把 MySQL 事务和事务隔离级别这件事彻底讲透。不管你是刚入行的后端开发还是准备面试的候选人又或者是已经在生产环境被并发问题折腾过的工程师都可以从里面找到能直接落地的认知。内容上我不打算只停留在背定义的层面而是会把 ACID 的因果链、三大读异常的本质、四种隔离级别的取舍逻辑、InnoDB 底层用什么机制支撑隔离性、以及生产环境到底怎么选、怎么配、怎么排查全部串起来讲。读完之后你至少能做到两件事一是面试时能把这个话题聊出深度二是线上再遇到脏读、不可重复读、幻读或者锁等待脑子里能立刻浮现出排查方向。1. 先搞清楚事务到底在保护什么1.1 一个转账场景逼出来的全部或全不我早年在交易系统里负责账户模块上线前做并发压测发现余额偶尔对不上——不是多扣就是少扣有时候 A 账户扣了钱B 账户却没加上。一开始以为是代码里 Redis 缓存和数据库不一致导致的查到最后才发现问题其实更基础一个批次的资金操作里前面几条 UPDATE 成功了后面有一条抛了异常但程序没有回滚已经扣掉的余额就再也回不来了。这就是事务要解决的最原始问题。一组数据库操作要么全部成功提交要么全部失败回滚不允许中间状态残留在数据库里。用银行转账来举例最直观A 账户扣 100B 账户加 100这两个 UPDATE 必须打包成一个整体。第一条成功、第二条失败时系统必须撤销第一条的修改把 A 的余额还原而不是让 100 块钱凭空蒸发。一个事务的边界在实际代码里通常就是一次业务操作的完整链路。比如下单可能涉及插入订单主表、插入订单明细、扣减库存、更新用户积分这一串操作只要有一个失败前面全部得回滚。很多刚入行的同学容易犯的错是把事务边界切得太碎或者依赖框架但没搞清方法边界结果事务没包住整个业务链路只包住了一条 SQL真出问题的时候一点保护作用都没有。1.2 ACID 不是四个孤立要求而是一条因果链教科书上把事务的特性概括成 ACID 四个字母但如果你只是把它们当成四条独立规则去背就永远理解不了事务的设计逻辑。在我看来这四个特性是有因果关系的原子性Atomicity事务是不可分割的最小执行单元。要么全做要么全不做。一致性Consistency事务执行前后数据库必须从一种合法状态变为另一种合法状态。这里说的合法包括所有约束字段非空、唯一索引、外键、金额不为负、状态流转合法等等。隔离性Isolation并发事务执行时彼此的操作不能被对方随意窥探到中间状态。隔离性解决的是并发带来的干扰问题。持久性Durability事务一旦提交修改就要永久保存下来即使机器宕机、进程崩溃数据也不丢。这四者的关系我倾向这样理解一致性是目标原子性和隔离性是达成目标的手段持久性是事后保障。说白了我们需要原子性来保证要么全部生效需要隔离性来保证并发执行时不互相污染两者共同服务的目标就是数据库在任何时刻都处于一个不违背业务规则的一致状态。而持久性确保这个状态不会因为宕机而倒退。你可能会问为什么现实里经常出现隔离性被放宽一致性崩了的情况举一个经典例子事务 A 扣减库存时读到了事务 B 未提交的扣减结果B 后来回滚了A 却基于那个假结果继续扣减最终库存被多扣。这个问题的源头就是隔离性不够导致一致性被破坏。所以不要把隔离级别当成一个可以随意切换的配置项它直接关系到业务的真实正确性。1.3 先分清哪些操作会入事务理解了事务的意义还得知道 InnoDB 下到底哪些操作参与事务。先说结论事务机制只对DML 语句INSERT、UPDATE、DELETE有意义。SELECT 一般不参与事务写入但会被隔离性影响读取行为DDL 语句CREATE、ALTER、DROP在 MySQL 中是隐式提交的也就是说执行一条 DDL 之前当前事务会被自动提交所以别指望 ALTER TABLE 能回滚。还有一个非常容易被忽略的配置MySQL 默认autocommit 1。这意味着如果不显式开启事务每一条 SQL 都是自己独立提交的。很多人写代码用 Spring 的Transactional注解发现注解加上了但方法内部调用了别的类的私有方法或者方法不是 public结果事务根本没生效——这就是典型的你以为在一个事务里实际每条 SQL 各玩各的。正确开启事务的方式是显式声明边界START TRANSACTION; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT;只要COMMIT没执行整个事务对其它事务来说就是不可见的受隔离级别影响。一旦某条语句出错执行ROLLBACK前面所有修改都会被撤销。这个是事务最基础的骨架后面讲隔离级别和锁全部建立在这个骨架之上。2. 并发一上来数据就脏了三大读异常2.1 脏读读到了别人还没提交的修改为什么需要一个隔离级别的概念而不是让所有事务严格排队执行因为在真实场景中并发是常态。当多个事务同时读写同一批数据时会产生不同类型的读异常数据库设计者需要权衡隔离到什么程度和允许并发到什么程度。最严重的问题是脏读Dirty Read。它的发生条件是一个事务读到了另一个事务尚未提交的数据。我用一个时序来演示时间事务A事务BT1UPDATE account SET balance 100 WHERE id 1;未提交T2SELECT balance FROM account WHERE id 1; -- 读到 100T3ROLLBACK;撤销修改balance 恢复为 200这个场景里事务 B 在 T2 时刻读到的 balance100是一个从未真正存在过的状态——因为事务 A 最终回滚了数据库的最终合法值仍是 200。B 基于 100 去做后续业务判断比如判断余额充足允许下单数据就已经被污染了。脏读是三种读异常里最恶劣的一种因为它读到的是假数据。任何有点节操的隔离级别都必须解决它。2.2 不可重复读同一句话问两遍答案不一样第二种异常是不可重复读Non-Repeatable Read。它的场景是同一个事务内执行两次相同的查询结果不一样。不一样的原因是另一个事务在这期间提交了修改。时间事务A事务BT1SELECT balance FROM account WHERE id 1; -- 读到 200T2UPDATE account SET balance 150 WHERE id 1; COMMIT;T3SELECT balance FROM account WHERE id 1; -- 读到 150注意B 的修改是已提交的所以不存在假数据问题。问题在于 A 的事务还没结束它两次读到的余额却不同。对于依赖一致性读的业务来说这是很要命的。比如在一个转账事务里第一步判断余额 200经过其他事务修改后第二步又按 200 做扣减但实际余额已经变成 150算出来的结果就错了。不可重复读的本质是行数据发生了 UPDATE 变化导致同一行在两次读取之间被替换成新值。要解决它就得保证一旦事务开始按某个快照读取数据后续读到的内容就是这个快照里的内容。2.3 幻读多出来的记录是最难缠的第三种异常是幻读Phantom Read。它与不可重复读有相似之处但攻击点完全不同同一个事务内两次查询返回的记录行数不一样。多出来的记录像幻影一样出现所以叫幻读。时间事务A事务BT1SELECT * FROM orders WHERE status PENDING; -- 查到 2 条T2INSERT INTO orders (...) VALUES (...); COMMIT; -- 新增一条 PENDINGT3SELECT * FROM orders WHERE status PENDING; -- 查到 3 条在 T1 和 T3 两次查询之间没有事务去 UPDATE 任何已有行但查询结果的行数变化了。原因在于 B插入了一条满足 A 查询条件的记录。比如 A 在统计待处理订单总数第一次统计是 2B 插了一条新订单后第二次统计变成 3。幻读最麻烦的地方在于它不能靠锁定已存在的行来解决。因为幻影行在 A 第一次查询时根本还不存在你要怎么锁一个不存在的记录这就引出了 InnoDB 里的间隙锁和 Next-Key Lock后面第四节会详细讲。三种读异常放在一起看异常类型本质涉及的操作是否读到未提交数据脏读读到未提交的修改UPDATE / INSERT / DELETE 后未提交是不可重复读同一行数据两次读取值不同已有行被 UPDATE 并提交否幻读同一范围两次查询行数不同新增或删除了满足条件的记录否2.4 为什么不能用全串行一劳永逸看到这里你可能会想数据库干脆把所有事务全部串行执行一个执行完再执行下一个不就什么问题都没有了理论上确实如此隔离级别里的 SERIALIZABLE 就是这个思路。但代价是并发的吞吐量断崖式下跌。你想一下双十一一秒几十万笔支付如果全部排队每一个读请求都要等前面的写操作提交整个系统的 RT 会成倍增长数据库马上就会被拖垮。所以事务隔离级别的本质是一个取舍在隔离程度和并发性能之间找一个平衡点。关系型数据库为此设计了一整套从宽松到严格的隔离级别体系让使用者根据业务对数据一致性的需求来决定付出多少并发代价。这就是为什么会有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE四档而不是一刀切。3. 四种隔离级别MySQL 默认档位到底强在哪3.1 READ UNCOMMITTED裸奔读基本不用于生产第一档叫READ UNCOMMITTED读未提交中文名很直白允许事务读取其他事务尚未提交的数据。这个级别在并发隔离上相当于裸奔三大读异常——脏读、不可重复读、幻读——它全都招架不住。实现上它几乎不加锁性能确实是最好的但它牺牲的恰恰是最基础的数据正确性。这个级别在生产环境几乎见不到原因无他读到未提交的假数据业务风险太大。我见过有的团队在跑大数据量的报表统计时尝试用它来提速结果运营看到的数据忽高忽低根本没法用。我的建议是除非你明确知道自己在做什么而且能接受数据可能是临时、不准确的否则不要在生产环境碰它。3.2 READ COMMITTED解决脏读放过不可重复读第二档是READ COMMITTED读已提交Oracle 的默认隔离级别。它解决的核心问题是脏读一个事务只能读取到其他事务已提交的数据未提交的修改对你不可见。但它没有解决不可重复读问题。原因在于READ COMMITTED 的实现机制是每次查询都重新生成一个一致性视图ReadView也就是说第二次 SELECT 时重新取一次当前已经提交的数据快照这样另一个事务在这期间提交的新变更就会立刻出现在你的视线里。这个特性对某些业务是优点对另一些则是坑。比如你事务里第一次 SELECT 出某用户优惠券的张数是 3 张事务还没结束另一个并发事务把它改成 2 张并提交你再查一次就变成了 2 张。如果你的业务逻辑是先读取、后基于读取的结果做判断更新那这种变化往往会带来逻辑错误。所以 READ COMMITTED 适合那些每次读都取最新已提交数据的业务不适合事务内要保证读一致性的业务。3.3 REPEATABLE READMySQL 的默认档能镇住幻读第三档REPEATABLE READ可重复读是 InnoDB 的默认隔离级别也是今天文章的主角。它的核心承诺是同一个事务内第一次读取时生成一个一致性视图后续所有普通 SELECT 都基于这个视图保证多次读取结果一致。也就是说它同时解决了不可重复读问题。这里有个很多初学者会搞错的知识点按照 SQL 标准REPEATABLE READ 并不能解决幻读标准里只有 SERIALIZABLE 才能解决幻读。但InnoDB 在 REPEATABLE READ 下通过 MVCC 快照读和 Next-Key Lock实际上把幻读问题也基本解决了。这也是为什么 MySQL 敢把它作为默认级别。这一点面试里特别容易考一定要记清楚标准定义下的 RR 不防幻读但 InnoDB 的 RR 默认防住了大部分幻读。那为什么 MySQL默认选择 RR而不是像 Oracle 一样选 RC这个问题我在 3.5 小节展开讲这里先记住一个结论InnoDB 的 RR 在保证较高并发性能的同时给事务内读取一致性提供了很强的保障对绝大多数业务来说它比 RC 更能避免莫名其妙的并发 bug。3.4 SERIALIZABLE彻底串行代价是垮掉的并发第四档SERIALIZABLE可串行化是隔离级别的天花板。它强制所有事务串行执行或者说让事件的执行效果等价于串行执行。实现上所有读操作都加共享锁所有写操作都加排他锁读和读之间还可以并发但读和写、写和写之间基本互斥。SERIALIZABLE 能保证 100% 隔离三大读异常一个都碰不到。但代价非常高昂锁竞争极其激烈并发量稍微大一点数据库的操作就会大量阻塞RT 飙升。生产环境里我很少见到有人把全局隔离级别设成 SERIALIZABLE它更适合作为某些极端关键操作的兜底而不是常规选择。顺带说一句如果某个场景真的需要串行化级别的强保证我更推荐的做法是把数据库隔离级别保持在默认的 RR然后在业务代码里对关键操作显式加锁或使用原子条件更新。这样既能保证业务逻辑的正确性又不会把整个数据库的并发能力搭进去。3.5 用一张表收拢四种级别的能力边界把四种隔离级别的能力和代价放在一张表里看最直观隔离级别脏读不可重复读幻读并发性能常见使用场景READ UNCOMMITTED存在存在存在最高几乎不用READ COMMITTED解决存在存在高Oracle 默认实时性要求高的读取REPEATABLE READ解决解决InnoDB 下基本解决较高MySQL 默认事务内多次读取需一致SERIALIZABLE解决解决解决最低极端要求一致性时才用注意表格里幻读那一列我在 REPEATABLE READ 写的是基本解决。这是因为 InnoDB 的 RR 存在快照读和当前读两条路径快照读下幻读被 MVCC 解决了当前读下幻读靠 Next-Key Lock 解决。但凡是实现机制就有边界后面我会专门讲这个边界在哪。再说回为什么 MySQL 默认可重复读。这个选择有历史原因。MySQL 5.x 早期版本主从复制基于statement 格式的 binlog也就是把主库执行过的 SQL 语句原样记录下发到从库执行。如果主库隔离级别是 READ COMMITTED两个事务并发执行它们的执行顺序在主库上是先 A 后 B但 B 的 SQL 记录在 binlog 里的顺序可能会因为提交时机不同变成先 B 后 A从库重放顺序和主库实际执行顺序不一致就会导致从库数据和主库不一致。而 RR 因为事务内读取一致性更强能更好地保证并发事务的最终结果一致。到了 MySQL 8.0默认 binlog 格式已经是 ROW这个历史约束弱化了很多但 InnoDB 的默认隔离级别仍然保留了 RR更多是出于兼容性和默认稳定性的考虑。4. 底层功臣锁、UNDO 版本链和 ReadView光说隔离级别能解决什么问题是不够的面试官和实际问题都会问你它是怎么做到的。这一节我拆开讲 InnoDB 的三样核心机制锁、UNDO 版本链和ReadView。这三者组合起来才是隔离级别落地的真正原因。4.1 锁的世界共享锁、排他锁与间隙锁先看锁。InnoDB 有两大类行级锁共享锁S Lock也叫读锁多个事务可以同时持有同一行的共享锁。持有共享锁期间其他事务可以继续加共享锁但不能加排他锁也就是大家一起读谁也不能改。排他锁X Lock也叫写锁一旦某个事务对一行加了排他锁其他事务既不能加共享锁也不能加排他锁只能等它释放。写入操作通常都需要排他锁。再加一个维度锁作用的范围记录锁Record Lock锁的是索引上的具体某一行。间隙锁Gap Lock锁的是索引记录之间的空隙防止其他事务在这个范围内插入新记录。临键锁Next-Key Lock其实是记录锁 间隙锁的组合范围是左开右闭区间既锁住已有行也锁住它们之间的空隙。在 REPEATABLE READ 级别下InnoDB 默认对索引记录使用 Next-Key Lock。举个例子SELECT * FROM orders WHERE id BETWEEN 10 AND 20 FOR UPDATE;这条当前读语句在 RR 下不止锁住 id10 到 id20 这些已经存在的行还会把 (10, 20) 这个区间内的所有空隙锁住让别的事务无法往这个范围插入新记录。这就是 InnoDB 在 RR 下防幻读的关键手段。但间隙锁是把双刃剑如果范围很大、并发插入频繁锁冲突和死锁的概率会明显上升这一点在性能调优时尤其要警惕。4.2 UNDO LOG 版本链每一次修改都留下存档MVCC 的全称是多版本并发控制Multi-Version Concurrency Control核心思想是一个数据行在数据库里可以同时存在多个历史版本事务读取时选择对当前事务可见的那个版本。InnoDB 中每行数据除了业务字段外还有两个隐藏列trx_id最后一次修改该行的事务 ID。roll_pointer指向 UNDO 日志里旧版本数据的指针。当你执行 UPDATE 时InnoDB 并不是把旧值直接覆盖掉而是生成一个新版本同时把旧版本信息写入 UNDO 日志形成一条版本链。比如一行余额数据从 200 被改为 150改的时候数据库保留 150 这个新版本同时通过roll_pointer指向保存着 200 的旧版本。如果之后的修改被回滚就可以顺着这条链找到旧值再还原。用一个账本来类比传统账本改错了直接涂改而 MVCC 的做法是另起一行记一条新记录每一条旧记录都还留着。每次修改就多一条存档多个事务并发修改同一行时这条版本链会变得越来越长。这也是为什么长事务和大事务会产生巨大的 Undo 日志因为它们让旧版本一直无法被清理。4.3 ReadView我该信哪个版本的签证官版本链保存了很多历史版本那么事务读取时到底取哪个版本这个决定由ReadView一致性视图来做。ReadView 就像一个签证官它拿着一份当时正在活跃的事务名单逐一检验版本链上的每个版本是否对当前事务可见。典型的 ReadView 包含这些关键信息m_ids生成 ReadView 时当前所有活跃未提交事务的 ID 集合。min_trx_id活跃事务 ID 中的最小值。max_trx_id下一个将要分配的事务 ID可以理解为将来事务的分界线。creator_trx_id创建这个 ReadView 的事务自己的 ID。判断一个版本是否可见的规则可以简化成四条如果版本的trx_id等于当前事务的creator_trx_id说明是自己修改过的数据直接可见。如果版本的trx_id小于min_trx_id说明这个版本在 ReadView 生成之前就已经提交可见。如果版本的trx_id大于等于max_trx_id说明这个版本是由 ReadView 生成之后才启动的事务产生的不可见。如果版本的trx_id在m_ids集合里说明产生这个版本的事务还没有提交不可见反之如果不在集合里说明已提交可见。如果当前轮到检查的版本不可见就顺着roll_pointer找到上一个版本继续判断直到找到第一个可见的版本。这个过程在面试里经常被问到能够清晰描述出来就说明你真的理解了 MVCC而不只是在背概念。4.4 当前读与快照读为什么 RR 还有漏网之鱼MVCC 的可见性判定发生在快照读路径上。日常执行的普通SELECT就是快照读它不加锁而是直接根据 ReadView 从版本链里找合适的版本返回。但UPDATE、DELETE、INSERT以及SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE这类语句走的是当前读路径。当前读必须读取版本链上最新已提交的版本然后对目标行加锁。原因很简单你要修改一行不能基于一个过期快照去改必须拿到此时此刻的最新值。这个差异解释了 RR 下一个微妙的现象快照读能防幻读但当前读依然可能遇到幻读。举个例子事务 A 先执行普通的SELECT查到一个范围有 2 条记录此刻它用的是自己的快照视图之后其他事务插入了新记录A 再执行普通 SELECT 还是只看到 2 条没问题。但如果 A 需要执行SELECT ... FOR UPDATE对范围内的记录加锁冲突就可能出现——加锁时它读到的可能是最新已提交数据从而看到新的行或者因为间隙锁和别的插入操作撞上锁。所以 InnoDB 在 RR 下防幻读实际上是两条路径分别处理快照读靠 MVCC 的 ReadView当前读靠 Next-Key Lock。理解了这个双轨机制你就不会再对RR 到底有没有解决幻读这个问题含糊。5. 生产环境的隔离级别怎么查、怎么改、怎么选5.1 查看和修改隔离级别的命令动手之前先记住几个最常用的命令。-- 查看当前会话的隔离级别 SELECT transaction_isolation; -- 或者 SHOW VARIABLES LIKE transaction_isolation; -- 修改当前会话的隔离级别只对当前连接生效 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 修改全局隔离级别只对之后新建立的连接生效 SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;需要注意的坑用SET GLOBAL修改后已经存在的连接不会立即生效必须重新建立连接才能看到新值。如果你只是想调试某一条慢 SQL 或某个具体场景优先用SET SESSION避免影响整个实例。生产环境想持久化配置更规范的做法是修改 MySQL 配置文件里的transaction-isolation参数然后重启或使用在线变更工具而不是直接跑全局 SQL。排查锁和事务状态时这几个查询比较有用-- 查看当前所有事务 SELECT * FROM information_schema.INNODB_TRX\G -- 查看锁信息MySQL 8.0 以后用 performance_schema SELECT * FROM performance_schema.data_locks\G SELECT * FROM performance_schema.data_lock_waits\G -- 查看死锁和最近报错信息 SHOW ENGINE INNODB STATUS\G线上出现事务迟迟不提交锁等待超时这类问题时这些命令能帮你快速定位到具体是哪个事务、持有了什么锁、阻塞了哪些语句。5.2 不同业务场景的档位选择思路隔离级别没有绝对的好坏只有适不适合。我给一个偏实用的选型思路电商订单、商品浏览这类读多写少、对实时性要求高的业务READ COMMITTED 一般够用它能保证每次读到的都是最新已提交数据并发吞吐也高。但要注意程序里如果有先 SELECT 后 UPDATE的判断型逻辑要小心两个事务之间读到旧值导致覆盖。报表统计、数据导出、事务内多次读取必须一致REPEATABLE READ 更省心。事务第一次 SELECT 生成快照后后续所有读取结果都一样你不会在生成一张报表的过程中看到数据忽多忽少。MySQL 默认 RR用着也顺。资金、库存、订单状态等强一致写场景不要指望隔离级别单方面解决所有问题。关键的读改写逻辑必须配合锁、条件更新或幂等设计否则就算你用上 SERIALIZABLE业务层逻辑不对照样出乱子。历史遗留系统迁移如果原来跑在 Oracle 上业务习惯依赖 RC 下的每次读最新值迁到 MySQL 后可以考虑在会话级别把它改成 RC避免业务对读取行为的不适应。一个容易被人忽略的点是MySQL 的 RR 和 Oracle 的 RR 行为完全不同。Oracle 的 RR 本质上是 session 级别的读一致性并没有真正锁住记录范围而 InnoDB 的 RR 通过 MVCC 和临键锁把读一致性做得更严格。所以不要拿着标准定义去套所有数据库的实现。5.3 最容易踩的坑长事务、锁等待和 Undo 膨胀我在生产环境踩过不少坑挑三个最常见、也最致命的分享给你。第一个是长事务。一个事务里塞了太多次查询、太多次更新或者程序忘了提交导致事务从开启到提交之间跨度极长。长事务的坏处有两层一是它长期持有锁阻塞其他事务二是它会拖住 Undo 版本链让旧版本无法被清理Undo 空间持续膨胀最终导致磁盘暴涨、性能骤降。排查时最直观的办法就是查INNODB_TRXSELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM information_schema.INNODB_TRX;如果发现某个事务trx_started已经是十几分钟甚至几个小时前基本可以判定是长事务需要找开发确认是否存在遗漏提交。第二个是大事务锁冲突。一次 UPDATE 影响的行数过多会持有大量行锁甚至间隙锁直接拖死其他正常操作。我之前遇到过一条 UPDATE 因为没有走索引全表扫描锁了几十万行线上其他写操作全部排队。解决办法是控制事务影响行数或者把大更新拆成小批次。第三个是间隙锁引发的死锁。两个事务并发操作同一个范围的数据时可能互相插入到对方的间隙锁范围内导致死锁。InnoDB 检测到死锁后会自动回滚其中一个事务但业务方如果不做重试用户就会看到一个报错。降低间隙锁冲突的一个思路是在明确不需要防幻读的场景下把隔离级别从 RR 改成 RC因为 RC 下 InnoDB 不会启用间隙锁。最后提醒一句改全局隔离级别一定要走变更流程别在线上顺手执行。这个操作影响的是整库所有连接的读写行为改错了影响面极大。6. 一次真实事故复盘订单状态被覆盖背后的隔离级别责任6.1 事故现场与直接现象有一段时间我维护一个订单服务并发量上来之后线上陆续收到用户投诉订单状态来回横跳。明明在用户端看到已经支付成功了刷新一下又变成处理中再刷新又变回已支付。同时库存扣减偶尔出现多扣。简化后的表结构大致是CREATE TABLE orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(64) UNIQUE, user_id BIGINT, status VARCHAR(16), -- PENDING / PROCESSING / PAID / CANCELLED pay_amount DECIMAL(10,2) );我们当时用的事务写法是典型的先查后改START TRANSACTION; -- 第一步查出订单当前状态 SELECT status INTO st FROM orders WHERE id 123; -- 第二步业务逻辑根据 st 判断是否允许流转 -- 伪代码if st PROCESSING then do something -- 第三步按新状态更新 UPDATE orders SET status PAID WHERE id 123; COMMIT;这个模式在单事务下没问题但一旦并发执行问题就来了。6.2 排查链路从现象反推隔离级别收到投诉后我们先把应用日志调出来看到同一条订单在两个线程里同时进入支付回调逻辑。线程 A 和线程 B 几乎同时发起事务都执行了第一步 SELECT此时订单状态都是 PROCESSING。A 从第三方支付平台回调返回成功后走了一套校验把状态更新为 PAID 并提交B 因为网络延迟在 A 提交之前就读到了 PROCESSING然后它也按照支付成功的逻辑走了一遍最终把状态又更新回 PAID——看起来都更新成 PAID那为什么用户会看到状态回退呢再往下查发现还有一条用户主动取消的路径。用户并发地点击取消线程 C 读到了 PROCESSING判断还没支付可以取消执行UPDATE orders SET status CANCELLED WHERE id 123。核心问题来了线程 C 的 UPDATE 执行时不管它最初 SELECT 到的是什么状态UPDATE 本身是当前读它会加锁并更新这行记录把状态改成 CANCELLED。而此时线程 A 已经支付成功完了但中间状态的读取和判断没有锁保护导致取消操作覆盖了已支付的状态。这里的关键不是RR 还是 RC的问题而是业务逻辑的读-判断-写三步之间存在间隙。隔离级别保证的是读的时候看到什么但它无法保证读完到写完这段间隙里别人不会改数据。换句话说锁和隔离级别只能管数据库层面的隔离管不了应用层基于过期数据做决策再写回的逻辑漏洞。6.3 修复方案与事后验证修复方向有三个按推荐程度排序一是原子条件更新把判断和更新合并成一条 SQL用 WHERE 条件做状态校验UPDATE orders SET status PAID, pay_amount 100.00 WHERE id 123 AND status PROCESSING;这条 SQL 只有执行成功的行数等于 1才说明状态确实是从 PROCESSING 合法的变成 PAID。如果返回 0 行说明状态已经被别人改了需要业务层自己决定要不要重试或报错。这样就从根上消除了先读再改的竞态窗口。二是乐观锁给订单表加一个version字段每次更新时带上版本号。三是悲观锁对关键行先执行SELECT ... FOR UPDATE把锁先拿到手再判断状态。但这是下策因为锁的持有时间会覆盖整个事务并发能力受损失严重。修复之后我们把订单状态、库存扣减都改成了条件更新 幂等控制支付回调增加唯一标志判断又压了一轮并发状态横跳和库存多扣问题都消失了。这个事故复盘想传递的观点其实很简单任何隔离级别都不是银弹。数据库给你的是读的行为约束而业务逻辑的正确性最终要靠读-改写的原子性设计来保证。遇到并发数据不一致第一反应不应该是要不要把隔离级别调成 SERIALIZABLE而是先审视自己的更新语句是不是安全的条件更新、是不是有幂等控制、是不是持有锁的时间太长。把这些做对了RR 甚至 RC 都已经足够撑起绝大多数业务场景。