1. 先搞懂一个底层问题MVCC到底在解决什么MySQL 的 MVCCMulti-Version Concurrency Control多版本并发控制是我这几年做金融类系统时觉得最值得反复咀嚼的一块东西。日常开发里你写一条 UPDATE 或 SELECT背后靠的其实是这套机制在支撑并发读写的稳定性。很多人背过“MVCC 是乐观锁的一种实现”或者“通过快照实现隔离”这些说法都对但真到你动手设计转账这一类资金流转系统时你会发现理解 MVCC 能决定你写出的是玩具代码还是能扛住对账的系统。为什么拿银行同行转账来做引子因为它是教科书级的强一致性场景。一个账户扣款另一个账户加款金额必须分毫不差而且同一时刻可能有几百笔转账打向同一个收款账户。如果在设计时没把 MVCC 的行为想清楚轻则出现“扣了钱但没到账”重则资金表出现负数。这个项目的核心考点不是“写个接口把余额改一下”而是并发下数据的一致性如何被 MVCC 保护以及在保护不了的地方你该补什么。这篇文章既适合刚接触 MySQL 隔离级别和事务的开发者也适合要做资金类业务但还没理顺“MVCC 行锁 幂等控制”这套组合拳的从业者。我会从 MVCC 的底层机制讲起再落到银行同行转账的领域建模与 SQL 实现中间穿插我实际踩过的坑。从认知层看MVCC 要解决的核心冲突是读与写同时发生时如何让读的人不阻塞写的人也不阻塞同时大家看到的还不乱套。那它凭什么做到凭“多个版本”。同一行数据在某个结构里保留了历史版本链不同事务可以根据自己的隔离级别选择看哪个版本。你不需要一把大锁把所有读写都串行化这就是 MVCC 的性能底气。不过要提醒一句MVCC 不是银弹它管的是“读”的提交可见性管不了“写写冲突”。转账场景里两条事务同时扣同一个账户余额MVCC 自身不会替你做串行化这需要另外的兜底手段核心是行锁和因此衍生的锁等待、死锁检测。所以 MVCC 从来不能脱离锁单独理解——它是读写之间的缓冲而锁是写写之间的闸门。搞懂这一点银行转账的事务设计才算入了门。2. 四个机制拆解 MVCC 的内部运行逻辑2.1 隐藏在每一行里的三个“隐形字段”先说 InnoDB 里一行数据除了业务字段之外还藏了哪些东西。你通常会忽略它们但它们才是 MVCC 的原材料。第一是DB_TRX_ID记录这行数据最近一次被修改时的事务 ID。事务 ID 在 InnoDB 内部是全局递增的你哪怕开 100 个连接同时操作每个新事务拿到的 ID 都比之前所有事务大。第二是DB_ROLL_PTR也就是回滚指针它指向 undo log 里的上一个版本。这意味着同一行数据的各个历史版本是通过这枚指针串成一条链的。第三是DB_ROW_ID在没有指定主键时 InnoDB 隐式分配的单调自增行 ID有主键的时候它不被使用。回想一下你平时看SHOW CREATE TABLE的输出压根看不到这些字段但它们在数据页里真实存在。正因如此MVCC 不需要额外建一张版本映射表所有版本信息都“贴着”行本身存储。这个细节在性能上很关键——查找历史版本时沿着回滚指针在 undo log 里走一两条链接就行成本相当低。2.2 undo log 里保存的不是“旧数据”而是“反操作”很多同学疑惑undo log 不是用来做事务回滚的吗怎么又是版本链其实两者用的是同一份数据只是用途不同。假如事务 A 把 balance 从 100 改成 80undo log 里会记录一个“逆操作”如果要回滚把 balance 改回 100。但从 MVCC 的角度看这份“旧值 100”并不是原始快照而是通过逆运算得到的逻辑版本。另一个事务 B 在 A 还没提交时去读这一行发现 DB_TRX_ID 是未提交的 A就沿着 DB_ROLL_PTR 找到旧版本读到的还是 100。这里我想强调一个容易懵的点undo log 里的版本并不等价于数据库里“真实存在”的整行数据。它是一个行数据的“差异记录”。所以当你需要沿着版本链往前翻好几个版本时InnoDB 会基于最新行数据依次回放逆操作来重建旧版本。如果版本链特别深是会影响读取性能的这也解释了为什么频繁更新同一行会让某些查询变慢。2.3 Read View 是事务与版本链之间的“滤镜”Read View 才是 MVCC 判断“哪个版本可见”的核心工具。它的工作方式非常像滤镜创建一个 Read View 时InnoDB 会记录当前活跃事务列表以及高低水位然后拿着这组信息去比对版本链上每个版本的 DB_TRX_ID。一次完整的可见性判断规则是如果版本的事务 ID 小于 Read View 的低水位值说明该版本在 Read View 创建之前就已经提交直接可见如果大于等于高水位值说明这个版本是未来事务不可见如果在高低水位之间但不在活跃事务列表里说明创建 Read View 时该事务已经提交可见如果还在活跃列表里则不可见继续沿回滚指针找更早版本。这就是为什么可重复读隔离级别下同一条 SELECT 反复执行结果一致——因为它用的是同一个 Read View。而在读已提交下每次 SELECT 都会生成新的 Read View所以能看到其他事务新提交的改动。我见过不少人在这块死记硬背实际上你手动扮演一次 Read View 判定流程就懂了把几个事务按 ID 排好拿着高低水位和活跃列表像查户口一样逐个版本问一句“你提交了吗”问完就出结果了。这个方法我一直推荐给团队新人效率挺高。2.4 隔离级别与锁的边界接下来把隔离级别和 MVCC、锁的关系串起来。直接说结论读未提交不会生成 Read View每次读都拿最新版本写写冲突依靠行锁但因为能读取未提交数据风险极大。读已提交每次读都新建 Read View解决了脏读但两次读可能拿到不同结果也就是不可重复读。可重复读是 MySQL 的默认级别事务开始时建一个 Read View整个事务内复用因此相同条件读到的结果始终一致。可串行化则会直接退化为读锁加写锁MVCC 的并发红利基本在侧重读场景下失效。有个实战要点可重复读虽然语义上隔绝了不可重复读但幻读问题并没有彻底解决——InnoDB 在 MySQL 层面还不是纯靠快照解决幻读而是通过当前读配合间隙锁Next-Key Lock来兜底。意思是你用快照读看不到新插入的行但你敢在当前读比如 SELECT ... FOR UPDATE下去查就会看到新行这时要靠锁把范围内的间隙锁住才防止并发插入。到这里你已经理解 MVCC 的整套骨架了隐藏字段存素材undo log 存旧版Read View 做判定行锁兜底写冲突。这四个零件合在一起才让 InnoDB 在并发读写压力下做到了“读不阻塞写、写不阻塞读”。3. 实操复盘手工走一遍 MVCC 的运行全过程3.1 准备实验环境与其看一百篇文章不如自己动手摆弄一次。拿 MySQL 8.x 做实验建一张极简账户表。CREATE TABLE account ( id BIGINT PRIMARY KEY, balance DECIMAL(12,2) NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0 ) ENGINEInnoDB; INSERT INTO account (id, balance, version) VALUES (1, 100.00, 0);先开两个终端会话模拟两个并发事务。终端 A 开始事务并更新余额但不提交终端 B 同时查询这笔数据看它会读到什么。如果你用的隔离级别是可重复读终端 B 会看到 100即便终端 A 已经在未提交状态把余额改成了 80。3.2 观察隐藏列和版本链想看隐藏列单纯 SELECT 是看不到的你需要直接指定列名。不过 InnoDB 在系统库里有一套接口可以查到部分信息如果使用 MySQL 8.0 的information_schema.INNODB_TABLES和INNODB_COLUMNS结合INNODB_METRCTS能看到表结构但最直观的方式还是对 undo log 下手那就太底层了。实际工作中我更建议直接通过EXPLAIN或performance_schema观察行锁等待而不是去翻数据页。这里有一个靠谱的观察技巧先开两个事务让事务 A 修改行但不提交紧接着事务 B 执行SELECT * FROM account WHERE id 1 FOR UPDATE你在第二个会话会立刻看到锁等待。等事务 A 回滚后B 的查询才会返回且拿到的还是 100。这一过程恰好说明当前读直接被行锁阻塞而普通快照读不受影响。3.3 可重复读与读已提交的读法差异接着做对比实验。开三个会话会话 A 开启事务并 UPDATE 1 号账户的余额从 100 改成 80不提交会话 B 开启事务后连续执行两次普通 SELECT第一次查询在 A 提交前进行看到 100然后 A 提交B 执行第二次普通 SELECT注意此时结果可重复读下仍是 100但在读已提交级别下刷新成 80。关键验证点在于可重复读因为复用同一个 Read View所以它感知不到新提交读已提交每次查询都生成新 Read View所以能看到变化。这个差异在银行转账业务里相当要命——如果转账系统的事务把“读余额”和“扣款”拆开并且业务方用读已提交你就得小心不可重复读导致余额在事务中途被改变。4. 从 MVCC 走到业务层银行同行转账的领域建模4.1 业务需求到底有哪些硬性约束刚才的 MVCC 只是地基真的往银行存款转账业务上建房子需要先梳理业务约束。我参与过好几个偏金融支付方向的项目这类系统的刚性需求大致是五条单笔转账要么全部成功、要么全部失败。扣款成功但加款失败是绝对不允许发生的。任何情况下不允许出现账户余额小于零。转账流水必须可追溯每笔资金的来源和去向要清楚。同一笔转账请求不能因为网络重试导致重复扣款或重复加款。并发场景下同一收款人同一时刻收到多笔汇款系统不能出现更新丢失。前两条是事务的基本要求。第三条要求你在 SQL 里必须带余额条件判断不能只依赖应用层代码先查后改。第四、第五是流水表和幂等键的重点。理解了这些约束以后再往下设计表结构和事务方向才不会歪。4.2 转账业务的核心表结构设计表是资金的骨架。同行转账最核心的两张表是账户表和流水表此外我强烈建议加一张“转账订单表”来做幂等控制。账户表负责存余额但这里有个误区不要在账户表里存“已转账次数”“可用额度”这类扩展信息保持表的职责单一。流水表是资金变动的明细账它不只做记录更是将来对账的底稿。转账订单表则单独承担幂等去重的责任。单表字段上我倾向给流水表加一个biz_id业务 ID。这个字段不是自增主键而是由业务方生成或由转账接口入参携带保证同一笔转账订单重复提交时系统能通过唯一索引直接拦下来。转账订单表也有自己的唯一订单号它和流水表的关系是一对一或一对多比如拆分了多笔入账但对同行转账的简单场景一对一是够用的。4.3 为什么账户表不需要幂等键一个容易被追问的点是既然要做幂等为什么不在账户表上做一个幂等字段原因是账户表的核心职责是余额本身不做请求级别的去重。转账订单表把请求去重做掉流水表把资金改动记录下来账户表只做行级余额变更这样每个数据结构只干一件事日后的维护成本会低很多。如果真把幂等键塞进账户表会造成一次转账要同时更新账户表两个属性事务范围变大行锁持有时间变长并发吞吐直接受到影响。听起来很细微真实线上环境放大后效果极其明显。5. 转账核心流程与 SQL 落地行锁怎么加、MVCC 怎么配合5.1 一版经得起追问的转账接口流程我把同行转账接口压缩成四个步骤校验 加锁、扣款、入账、记流水。这里有个规划要点第一步不能“先 SELECT 出来看看余额够不够再 UPDATE”必须把 UPDATE 语句本身当作唯一的余额校验手段。因为第一步如果只是普通 SELECT你拿到的 MVCC 快照可能和最终实际余额不一致并发时会出现更严重的逻辑漏洞。正确做法是直接发出一句带条件判断的 UPDATE。UPDATE account SET balance balance - 100.00 WHERE id 1 AND balance 100.00;如果影响行数为 0说明余额不足或账户不存在直接返回失败影响行数为 1则锁定了这一行后续操作你才真正“拥有”这笔行数据的更新权。5.2 扣款与加款的先后顺序为什么强烈要求先扣款在同行转账场景里先扣付款方账户的款再给收款方账户加款这个顺序可以作为一条纪律看待。原因有两个第一从资金安全角度扣款成功是入账的前提。试想一下你先把入账做掉再扣款万一扣款那一步因为余额不足挂了回收资金会变得非常麻烦。第二从锁竞争角度扣款行锁的申请先于加款行锁能降低死锁出现概率。死锁出现的一个典型原因是两个事务以相反顺序申请多把行锁如果你把所有转账事务都定成先扣后加、先小账户后大账户之类的统一顺序死锁的暴露面就小很多。还有人会问如果收款方支行和付款方支行是不同 MySQL 实例那不就是跨库转账那就要引入分布式事务这里只在“同一个 MySQL 实例”的同行转账边界下讨论跨行、跨库暂时不展开不过后续我可以单独写一篇。5.3 完整转账事务的伪代码与真实 SQL结合上面的思路完整的转账事务可以这样组织START TRANSACTION; UPDATE account SET balance balance - 100.00 WHERE id 1 AND balance 100.00; SELECT ROW_COUNT(); -- 若为 0ROLLBACK UPDATE account SET balance balance 100.00 WHERE id 2; INSERT INTO transfer_order (order_id, from_acct, to_acct, amount, status) VALUES (ORDER20250101001, 1, 2, 100.00, SUCCESS); INSERT INTO account_flow (flow_id, acct_id, change_amount, order_id) VALUES (FLOW20250101001, 1, -100.00, ORDER20250101001), (FLOW20250101002, 2, 100.00, ORDER20250101001); COMMIT;这里要注意两点两条流水我放在 INSERT 里一次完成减少与数据库的交互次数订单号 ORDER20250101001 在转账订单表有唯一索引重复提交会因为主键冲突或唯一键冲突直接告警从而做到幂等。为什么这个事务能适配 MVCC因为加款步骤的 UPDATE 会用到当前读实时把收款账户的最新行锁住并更新而事务内的 SELECT如果有会使用快照读看到的是事务开始时的版本。读与写各走各的机制互不阻塞最终一致性由 COMMIT 决定。5.4 行锁等待、死锁与超时参数再聊几个你在真实压测时几乎必遇的问题。转账事务里两条 UPDATE 都会申请行锁如果事务 A 先锁了账户 1 再等账户 2事务 B 先锁了账户 2 再等账户 1就会形成死锁。InnoDB 会自动探测死锁并回滚其中一方但被回滚一方可能已经执行了大半逻辑。所以“给所有转账统一加锁顺序”是有效规避手段。另外要调整innodb_lock_wait_timeout很多数据库默认是 50 秒。在转账业务下这个值往往太长用户根本没办法等那么久而且长锁等待也会拖垮连接池。实践中我会把锁等待超时调低到 5 秒以内把超出的请求引导到重试队列或直接返回“系统繁忙”。要知道高并发下宁可快速失败也比让用户无限转圈好。5.5 幂等防重试是转账的“安全气囊”网络超时到底是扣款成功还是没成功这是所有支付类业务都要正面处理的疑难问题。解决它靠的是幂等键。转账接口接入层收到请求后先以订单号去查转账订单表存在则直接返回上一次的处理结果不存在才发起真正的转账事务。有人问我订单号查询会不会有性能瓶颈其实完全不会。用订单号的唯一索引查一次而且每次转账都只用一条极短主键查询成本很低。面对极端连点或调用方重试时这笔开销远小于资金错的代价。6. 常见问题与排查实录问为什么我明明开了事务整个事务内 SELECT 出来的余额还是旧值答你大概率用的可重复读事务内第一条普通 SELECT 建立 Read View后续快照读都以此为准。想读最新已提交数据用当前读SELECT ... FOR UPDATE或FOR SHARE。问UPDATE 行数返回 0但余额明明够这是什么原因答先检查 UPDATE 条件里的 balance 字段是否和表结构一致尤其是 DECIMAL 精度和类型转换。曾经有同事误把字段定义成 INT金额在应用层按分存储导致 SQL 里写balance 1判断出错排查了半小时。字段约束和单位统一是隐形大坑。问同时给一个收款账户打 1000 笔钱会不会出现同一行被串行更新、性能剧降答一定会的。收款账户在同一行上加款天然是热点行。并发越高锁等待越严重。要解决这个热点常见思路是把收款账户余额拆成多个子账户或者用异步汇总这类方案。这个优化属于架构层面初版系统大可不必做但你要心里有数。问MVCC 能不能防止“扣款成功后写入流水失败”答不能。流水表插入失败会导致整个事务回滚扣款也随之回滚。MVCC 管的是可见性事务原子性靠的是 undo log 和回滚机制两者不冲突。做资金类系统时你得把“任一环节失败即 ROLLBACK”写在事务边界能覆盖的范围内不能把写流水放在事务外。问用了行锁是不是就安全了要不要再加乐观锁 version 字段答看场景。行锁解决的是同一行并发更新的互斥问题MVCC 解决的是读写隔离问题version 乐观锁解决的是“读取期间数据被别人改了”的检测问题。对转账来说余额扣减语句已带条件判断行锁已提供互斥再加 version 属于冗余设计但如果你做的是修改用户资料这类“先读后改”弱一致性场景乐观锁 version 查改非常有效。不要盲目堆机制先分清冲突类型。问同城同行转账是否还需要“分布式事务”或“消息队列”答不需要。同库多行更新一个本地事务就能搞定。即使以后拆库、拆成多个服务也要先明确是否真的跨越了数据库实例再决定引入方案否则就是为架构复杂度自掏腰包。我在实际排查过一个线上事故由于一个定时任务对同一行数据做大范围更新长时间持锁导致大量转账事务进入锁等待接口耗时飙到十秒。当时我们加了一整套监控重点看information_schema.INNODB_TRX里活跃事务的持续时间、performance_schema.data_lock_waits里的锁等待关系才定位到是同一把行锁引发的事故。现在每回设计新系统我都会提前确认是否有“长事务 热点行”这种组合雷区。最后再分享一个小技巧建表时给账户表加一列updated_at每次更新顺手维护它。排查锁问题时你会发现一个长时间未更新的updated_at往往意味着某个事务持锁已久这比分析事务 SQL 直观得多。转账系统越往后做排查手段和预防意识就越比某条 SQL 的写法值钱。
