多版本并发控制MVCC这六个字但凡做过后端开发或者数据库运维的人都见过。面经里它是高频八股生产环境里它却是各种疑难杂症的病根明明没有死锁事务却一直报锁等待超时明明数据量没涨多少undo 表空间却涨得飞快明明加了一堆索引统计查询还是越跑越慢。这些问题的背后几乎都能拽出一个被晾了很久的 ReadView或者一条过长的版本链。这篇就把多版本并发控制这堂课补讲一遍不背概念只讲它到底怎么工作、为什么这么设计以及线上遇到问题该怎么查。1. 没有MVCC之前并发读写是怎么互相折磨的1.1 朴素方案读-写互斥带来的连锁反应想象一张订单表业务上要支持用户不断下单INSERT也要支持运营跑月度汇总SELECT SUM/COUNT。如果没有多版本机制最简单可靠的做法是给行加锁读的时候加共享锁写的时候加排他锁。共享锁和排他锁互斥这意味着只要有人在读某一行写就必须等着反过来有人正在写读也得阻塞。在低并发时代这套逻辑没什么问题但放到电商大促期间如果一个汇总查询扫了全表且跑了十几秒这十几秒内所有对订单表的写入都会被堵住客户端连接开始堆积连接池被打满紧接着整个应用雪崩。这是典型的读-写互斥连锁反应。你可能会说那把查询放到从库去不就行了主从延迟且不说业务上很多查询必须看到最新数据没法完全拆出去。而且只要并发模型还是读写互斥即使拆了库主库上的热点更新照样会被主库自己的读操作阻塞。所以问题根源不是 SQL 写得不好而是同一份数据只有一个当前值读和写天然只能抢这一个值。1.2 换个思路让读看到以前的样子既然问题出在同一份数据只有一个当前值那能不能让读操作不非要拿最新值而是拿一个在那个时刻看起来正确的旧版本这其实就是多版本并发控制的出发点。数据库为每一行数据的修改保留历史版本读操作选择一个合适的版本去读写操作继续在当前版本上改两者各走各的路互不阻塞。这种设计很像图书馆里一个人借走了书另一个人还可以通过影印本读到同样的内容不需要等书还回来。关键洞察是牺牲一点读到最新的时效性换取读写并发度的巨大提升。对绝大多数业务来说读到某个时间点的一致性数据完全够用真正需要永远读最新的场景反而是少数。1.3 多版本不是完全不用锁这里必须说清楚MVCC 并不是把锁机制废除了它解决的是读-写之间的阻塞问题写-写之间仍然必须用锁来保证不丢数据。你 UPDATE 一行的时候InnoDB 还是要拿 X 锁别的写者得排队。另外INSERT 还可能涉及间隙锁、意向锁这些也都是锁机制的一部分。所以更准确的理解是MVCC 把传统笨重的读写互斥拆成了两条路径读走快照路径写走加锁路径。当读想看到最新提交状态并准备修改时就会主动走加锁路径这就引出了快照读和当前读的区分后面会细聊。先记住这个结论MVCC 是用版本空间换并发时间不是用无锁换并发。2. 版本链与ReadView多版本到底是怎么存出来的2.1 隐藏列与undo log每一行都背着历史包袱InnoDB 中聚簇索引的记录行不只存用户定义的列还会悄悄多出几个隐藏列DB_TRX_ID 表示最近一次修改这条记录的事务 IDDB_ROLL_PTR 指向该记录上一个版本的 undo log 记录。这俩是 MVCC 的地基。当一个事务更新某一行时InnoDB 会把修改前的旧值以及必要信息写入 undo log然后把数据行的 DB_ROLL_PTR 指到这条 undo 记录DB_TRX_ID 改成当前事务 ID。如果同一个事务对同一行改了多次undo 里就会串起一条版本链每次读的时候通过 DB_ROLL_PTR 从当前版本一路向前找旧版本。注意INSERT 的 undo 在事务提交后就可以扔掉因为新插入的行对任何其他事务来说只有提交后才能看到提交之后旧版本就没有存在意义了。但 UPDATE/DELETE 产生的 undo 必须留着因为可能有另一个事务的 ReadView 还需要沿着版本链读到修改前的数据。还有个细节值得记住DELETE 本质上也是一种 UPDATE只是在记录上打上删除标记delete bit真正的物理删除要等 purge 线程把历史版本清掉之后才执行。从这里能看出MVCC 的多版本并不是把历史版本全都放在数据页里而是尽量少动数据页把旧版本堆到 undo 里。这也为后面讲 undo 膨胀埋下伏笔。2.2 ReadView四个字段可见性判断的一套水位线有了版本链下一步问题就是某个版本对当前事务是否可见InnoDB 引入 ReadView 来回答这个问题。生成 ReadView 时会记录以下关键信息m_ids当前系统中所有活跃未提交的读写事务 ID 列表。min_trx_idm_ids 中最小的那个事务 ID。max_trx_id生成 ReadView 时系统即将分配的下一个事务 ID也就是在这个快照建立之后才可能出现的 ID 水位线。creator_trx_id创建这个 ReadView 的事务自己的 ID。判断规则我整理成表格这是理解 MVCC 的钥匙条件判断结果版本 trx_id creator_trx_id可见自己改的版本 trx_id min_trx_id可见事务已提交版本 trx_id max_trx_id不可见事务还没开始min_trx_id trx_id max_trx_id在 m_ids 中则不可见不在则可见看完规则你可能还觉得抽象我举个具体例子。假设事务 AID100插入一行并提交事务 BID200开启事务执行 SELECT生成 ReadView 时活跃事务还包括事务 CID300此时 min_trx_id200max_trx_id301creator_trx_id200。版本链上这行的 trx_id100因为 100 小于 min_trx_id说明事务 A 早已提交所以 B 能看到。紧接着事务 CID300UPDATE 了这行版本链头部 trx_id 变成 300300 在活跃事务列表 m_ids 中B 的 ReadView 判断这个新版本不可见于是沿链向下找最终返回 trx_id100 的旧版本。这就是瞬间快照的真相它并不是靠保存一份完整数据副本实现的而是靠跳过不可见版本、找到第一个可见版本实现的。2.3 别把MVCC理解成按时间回溯一个常见误解是多版本并发控制是靠时间戳实现的半个小时前的读应该看到半个小时前的数据。其实 InnoDB 完全不看墙钟时间它看的是事务 ID 的先后顺序以及事务是否提交。事务 ID 的分配顺序基本可以理解为事务开始顺序但提交顺序和开始顺序不一定一致所以谁先提交谁可见也不完全准确真正决定可见性的是生成 ReadView 那一刻的活跃事务集合。这种设计的好处是读操作无需等待其他事务提交就能立刻执行坏处也很明显如果一个事务一直不提交它会长期占着一个活跃位置把所有后续版本的可见性判断都拖住。很多数据库故障的本质就是有一个早已被遗忘的事务却还躺在活跃事务列表里让其余所有事务都得绕着它走。3. 快照读与当前读的边界为什么RR还躲不开幻读RC到底读什么3.1 两种读法最大的差异在是否加锁日常写的 SELECT 是快照读InnoDB 直接根据 ReadView 在版本链上挑选合适的版本返回整个过程不加任何行锁所以它不阻塞写写也不阻塞它。而 SELECT ... FOR UPDATE、SELECT ... FOR SHARE、UPDATE、DELETE、INSERT 这些语句属于当前读它们必须读取最新的已提交版本并且对读取到的记录加锁X 锁或 S 锁。当前读不会走版本链找旧版本不是它不能而是它必须拿最新的否则更新就会基于一个过期版本那叫丢失更新。举个实际案例两个事务同时读同一行都读到 val1然后都执行 UPDATE valval1如果都基于旧值计算最终结果会是 2 而不是 3。当前读加锁的意义就在于保证读到的值在计算期间不会被人改掉。这一点在写业务代码时特别重要很多人以为 MVCC 能保证一切一致性结果在并发扣库存时出了大问题。3.2 可重复读RR第一次快照读时ReadView就定终身MySQL 默认隔离级别是可重复读REPEATABLE READ简称 RR。在 RR 下InnoDB 的实现是事务中第一次执行快照读时生成 ReadView此后直到事务结束这个 ReadView 都不再变化。也就是说一旦你在这个事务里跑了第一个 SELECT你看到的数据库就定格在那个水位线上后续其他事务提交再多数据你事务内再跑多少次快照读看到的都是一样的结果。这里有个容易忽略的细节如果事务一开始执行的是 UPDATE当前读之后才做 SELECTReadView 的生成时机是第一次快照读不是事务开始。所以不要把 RR 理解成从头到尾都一样它实际上只是从第一次快照读开始快照结果不变。看一个例子session A:START TRANSACTION; SELECT * FROM t WHERE id1; -- 此时生成ReadView读到旧值session B:UPDATE t SET val100 WHERE id1; COMMIT;session A 继续SELECT * FROM t WHERE id1; -- 快照读依旧读到旧值 SELECT * FROM t WHERE id1 FOR UPDATE; -- 当前读读到新值100这个现象很反直觉但特别重要。很多业务在 RR 下用 SELECT FOR UPDATE 做并发校验依然能读到最新数据就是因为它绕过了 MVCC 走了当前读。如果你用普通 SELECT 去做条件判断再更新就容易出现基于过期快照的误判。3.3 读已提交RC每条语句一个新的ReadView读已提交READ COMMITTED简称 RC隔离级别下每个快照读语句执行时都会重新生成一个 ReadView所以其他事务提交的新数据在下一条 SELECT 中就能看到于是同一个事务内两次相同的查询可能得到不同结果这就是不可重复读。RC 下没有定终身的概念。很多云数据库默认使用 RC原因很直接并发高、事务短不想让旧视图拖累 undo 回收。如果你的核心诉求是同一事务内两次查询必须一致那才需要 RR。在业务选型时我通常建议先用 RC 起步除非有明确的一致性读取需求否则 RR 带来的历史版本保留成本可能比想象中高。3.4 幻读MVCC没堵住的洞要靠next-key lock来补MVCC 能保证快照读的一致性但幻读这个经典问题在 RR 下依然可能出没尤其是在当前读和插入交错出现的场景。例如一个事务反复执行 SELECT * FROM t WHERE create_date BETWEEN ... FOR UPDATE第一次查到 5 条另一个事务插入了一条符合条件的新数据并提交这个事务再执行同样的当前读会看到 6 条记录。前后两次读到的行集合不一样这就是幻读。InnoDB 在 RR 下用 next-key lock记录锁 间隙锁来压制幻读当某个事务对范围内的记录加锁时会把范围内的间隙也锁上其他事务无法在这个 gap 里插入新行从而保证当前读阶段性不出现幻读。但间隙锁开销不小而且很容易引发死锁特别是两个事务互相在对方间隙里插入数据时。所以理解 MVCC 边界时脑子里要时刻有两条线一条是版本链上的快照读一条是加锁的当前读。很多线上死锁都是把这两种读混在一起用出来的。4. InnoDB的MVCC不是孤军奋战undo log、purge线程与锁的三角关系4.1 两种undoinsert undo与update undo的寿命不一样InnoDB 把 undo 分成了两类insert undo 和 update undo。insert undo 专门服务于 INSERT 操作事务提交后任何 ReadView 都不会关心这个新版本因为新插入的行对别的活跃事务来说要么不可见未提交要么已经可见已提交都不需要再看所谓的插入前状态所以这条 undo 可以直接删除。update undo 服务于 UPDATE 和 DELETE承载着修改前的旧版本。只要系统中存在一个可能还需要读到旧版本的 ReadView它就不能被清掉。理解这个差别对排查 undo 膨胀至关重要如果数据库的 undo 表空间一直涨十有八九是 update undo 堆积。单纯的 INSERT 流量再大也不会造成历史版本堆积因为 insert undo 提交即焚。4.2 purge线程清理逻辑与history list lengthpurge 线程负责两件事把标记删除的记录真正物理删除回收不再需要的 undo log。判定一条 undo 是否不再需要取决于系统中最早的 ReadView 覆盖到哪里。如果一个长事务开启了一个 ReadView 后一直不提交从它的视角看所有在它之后产生的版本都是不可见的未来版本为了支持这个长事务之后继续沿版本链读数据库必须把这条版本链上所有旧版本都保留着purge 线程就不能往前走。这时 SHOW ENGINE INNODB STATUS 里的 History list length 这个数字会持续抬升undo 表空间占用只增不减。这个指标比表行数更能反映 MVCC 的健康度。健康实例的 History list length 通常很低一旦长期高于几十万甚至上百万那就说明有活跃事务挡住了清理。很多 DBA 巡检只看 QPS、慢查询忽略了这个指标结果磁盘被 undo 吃掉大半才后知后觉。4.3 长事务与空事务是undo膨胀最常见的推手很多应用喜欢在业务代码里手动 BEGIN然后查完不 COMMIT连接被连接池回收后事务还开着。更隐蔽的是那些只读连接一条 SELECT 执行完没有显式事务但如果连接设置了 autocommit0下一次 SELECT 仍然在同一个事务里ReadView 不断刷新倒还好最怕的是事务一直开着不提交把最老的活跃 ReadView 卡死在那里。真碰到这种情况单靠改代码不够得先定位到具体连接。可以快速找出活跃时间最长的业务事务SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_age_seconds, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx ORDER BY trx_started ASC LIMIT 10;trx_started 最早的往往就是那块最老的绊脚石。注意 information_schema.innodb_trx 里空事务的 trx_query 可能为 NULL因为它在等待下一条语句但 trx_started 已经暴露了它开启时间有多久。很多人习惯看 processlist 中的 Sleep 状态来判断有没有问题结果发现连接状态是 Sleep 就以为没事其实事务早就开启了这就是排查误区。4.4 一致性读对主从延迟和备份同样有影响MVCC 并不只影响在线查询。mysqldump --single-transaction 就是利用 InnoDB 的 MVCC 做全局一致性快照备份备份过程中如果有大量 DMLundo 要尽量保留完整版本备份实例的资源会被拖高。主从同步也一样从库应用 binlog 时如果同时有客户端在做长查询从库的 undo 也会堆积。理解了 MVCC 之后你会发现数据库里的每一样新功能几乎都在跟旧版本还能不能清掉这件事博弈。备份、同步、在线加索引、统计信息采集全都依赖于一致性读又全都受制于一致性读。所以一个健康稳定的数据库不只是 SQL 写得快更要管理好那些看不见的版本。5. 实战复盘一次慢查询与undo膨胀的排查过程5.1 现象磁盘涨了CPU没爆我接手过的一个线上 MySQL 实例表现很典型磁盘使用率每周增长几个百分点但 CPU、IO 都还算正常。业务方反馈某张经营分析表的统计结果越来越慢明明加过索引。这时候第一反应不应该是去看 SQL而是先看 undo 和事务。我执行 SHOW ENGINE INNODB STATUS发现 History list length 已经到几百万健康实例这个值应该很低。再查 information_schema.innodb_trx果然有一个 trx_started 已经超过 3 小时的连接状态是 RUNNING但 trx_query 为 NULL。这个连接不是正在跑 SQL而是开着事务等下一个请求——典型的连接池复用导致的僵死事务。5.2 定位到具体业务连接拿到 trx_mysql_thread_id 后到 performance_schema.threads 或者直接看 processlist 去找到对应连接。这里有个很容易踩的坑只看 processlist 中 Command 是 Sleep 就判断连接空闲实际上事务可能早就在第一次 SELECT 时就开启了连接虽然 Sleep事务并没有提交。正确做法是看 information_schema.innodb_trx 的 trx_started而不是看 processlist 的 Command。很多排查工具默认把Sleep 连接当成无害空闲连接过滤掉这在没有 MVCC 的模型下问题不大但在 InnoDB 下大错特错。空闲连接和空闲事务是两码事一个空闲连接可能是一个正在挡着全局 purge 的长事务。5.3 处理kill连接还是等它结束这种僵死事务如果业务没有闭环最优策略是先通知业务再评估是否要 kill。KILL 掉连接会回滚它持有的事务如果这个事务改过很多行回滚可能要一两分钟甚至更久期间实例会有瞬时压力。如果只是只读事务直接 kill 没什么心理负担。处理完之后还要让运维把这条 SQL 加入巡检每天跑一次SELECT trx_mysql_thread_id, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age FROM information_schema.innodb_trx WHERE trx_started NOW() - INTERVAL 5 MINUTE;超过 5 分钟的事务单独报警。别小看这条规则很多团队把阈值设为 1 小时等报警出来时 undo 可能已经吃掉几十 GB 了。5.4 从脏数据看MVCC参数undo表空间回收不是重启就能解决MySQL 8.0 默认支持 undo 表空间自动截断innodb_undo_log_truncate但自动回收有个大前提没有活跃的旧 ReadView 遮挡。所以单纯调大 undo 表空间治标不治本根子还是把业务事务缩短。更重要的是不要指望 MySQL 重启能把 undo 清掉。重启后 InnoDB 会根据 redo 恢复未提交事务也会重新加载 undo 表空间膨胀依旧。我见过有人用重启来缓解 MVCC 问题结果启动起来 History list length 原封不动白忙一场业务还平白多了一次不可用时间。6. 从MVCC看数据库的取舍InnoDB、PostgreSQL与其他实现的分野6.1 InnoDB原地更新 undo版本链InnoDB 的 MVCC 是基于旧版本放账外的思路数据页上的记录只保留最新值旧版本塞进 undo log。好处是数据页不会因为多次更新产生大量碎片索引维护相对简单聚簇索引不需要紧跟每个版本坏处是读一个旧版本要顺着 roll_pointer 链回放链越长回放越贵而且 undo 的清理与索引修改关系复杂。这也是为什么长事务在 MySQL 上比在 PostgreSQL 上更容易引发性能事故。一个几万条记录的版本链每次读取都可能要沿链走好多跳对热点行的访问可能从微秒级变成毫秒级。再加上 purge 线程如果跟不上版本链会进一步变长形成恶性循环。6.2 PostgreSQL新版本直接堆在数据页里靠vacuum回收PostgreSQL 走的是另一条路。它的堆表里更新时会生成一个新 tuple旧 tuple 仍然留在原数据页里通过行头字段 xmin/xmax 标记可见性范围。更新时旧 tuple 的 xmax 被标记为当前事务 ID新 tuple 的 xmin 等于当前事务 ID。读事务判断元组是否可见主要看 xmin/xmax 与自己的事务快照之间的对比。这样做的好处是读旧版本不需要回放 undo 链版本可见性判断通常更稳定坏处是数据页会被死 tuple 占满查询可能要扫描更多页所以需要 VACUUM 清理死 tuple 和更新可见性映射。PostgreSQL 的表膨胀问题本质上也是 MVCC 的代价。我整理一个快速对比表方便你记住两者差异维度InnoDBPostgreSQL多版本存储数据页放最新值旧版本写 undo log新旧版本都在数据页旧版本等待 vacuum读旧版本方式沿 undo 版本链回放直接读页内旧 tuple空间回收purge 线程清理 undovacuum 清理死 tuple长事务影响undo 膨胀、版本链变长死 tuple 堆积表膨胀索引影响索引基本不受影响索引项可能指向死 tuplevacuum 需要清理这对架构选型有现实意义如果业务写多读少、更新频繁PostgreSQL 的表膨胀可能要投入更多维护精力如果业务里大量长事务、事务不结束InnoDB 的 undo 膨胀又很致命。关键是要理解自家业务的事务形状而不是唯性能论。6.3 其他实现Oracle的UNDO与SQL Server的版本隔离Oracle 的读一致性也依赖 UNDO 段通过 SCN系统变更号构造一致性读版本和 InnoDB 的 undo 思路同源。SQL Server 默认的 READ COMMITTED 是锁定读但如果开启 READ_COMMITTED_SNAPSHOT读操作会读 tempdb 中的行版本这又是另一种取舍。这些实现五花八门但万变不离其宗要么保存旧版本要么生成新版本目的都是让读不被写阻塞。理解 MVCC 的时候先问清楚这个数据库维护的到底是旧版本还是新版本比背一堆参数更有用。6.4 千万别把MVCC当成免死金牌最后说点个人体会。MVCC 的确解决了读写互斥但它引入了新的维护成本undo、死 tuple、purge、vacuum、间隙锁、版本可见性判断。你在索引设计、SQL 优化、事务拆解上的每一个偷懒最终都可能被 MVCC 的放大效应反噬。所以每当我看到数据库性能报警脑子里不再只有加索引这个选项还会多问一句是不是有一个读视图挡着一切让数据库在替一个早已忘了提交的事务打工能回答好这个问题比记住 ReadView 的四个字段值钱得多。
多版本并发控制MVCC这六个字但凡做过后端开发或者数据库运维的人都见过。面经里它是高频八股生产环境里它却是各种疑难杂症的病根明明没有死锁事务却一直报锁等待超时明明数据量没涨多少undo 表空间却涨得飞快明明加了一堆索引统计查询还是越跑越慢。这些问题的背后几乎都能拽出一个被晾了很久的 ReadView或者一条过长的版本链。这篇就把多版本并发控制这堂课补讲一遍不背概念只讲它到底怎么工作、为什么这么设计以及线上遇到问题该怎么查。1. 没有MVCC之前并发读写是怎么互相折磨的1.1 朴素方案读-写互斥带来的连锁反应想象一张订单表业务上要支持用户不断下单INSERT也要支持运营跑月度汇总SELECT SUM/COUNT。如果没有多版本机制最简单可靠的做法是给行加锁读的时候加共享锁写的时候加排他锁。共享锁和排他锁互斥这意味着只要有人在读某一行写就必须等着反过来有人正在写读也得阻塞。在低并发时代这套逻辑没什么问题但放到电商大促期间如果一个汇总查询扫了全表且跑了十几秒这十几秒内所有对订单表的写入都会被堵住客户端连接开始堆积连接池被打满紧接着整个应用雪崩。这是典型的读-写互斥连锁反应。你可能会说那把查询放到从库去不就行了主从延迟且不说业务上很多查询必须看到最新数据没法完全拆出去。而且只要并发模型还是读写互斥即使拆了库主库上的热点更新照样会被主库自己的读操作阻塞。所以问题根源不是 SQL 写得不好而是同一份数据只有一个当前值读和写天然只能抢这一个值。1.2 换个思路让读看到以前的样子既然问题出在同一份数据只有一个当前值那能不能让读操作不非要拿最新值而是拿一个在那个时刻看起来正确的旧版本这其实就是多版本并发控制的出发点。数据库为每一行数据的修改保留历史版本读操作选择一个合适的版本去读写操作继续在当前版本上改两者各走各的路互不阻塞。这种设计很像图书馆里一个人借走了书另一个人还可以通过影印本读到同样的内容不需要等书还回来。关键洞察是牺牲一点读到最新的时效性换取读写并发度的巨大提升。对绝大多数业务来说读到某个时间点的一致性数据完全够用真正需要永远读最新的场景反而是少数。1.3 多版本不是完全不用锁这里必须说清楚MVCC 并不是把锁机制废除了它解决的是读-写之间的阻塞问题写-写之间仍然必须用锁来保证不丢数据。你 UPDATE 一行的时候InnoDB 还是要拿 X 锁别的写者得排队。另外INSERT 还可能涉及间隙锁、意向锁这些也都是锁机制的一部分。所以更准确的理解是MVCC 把传统笨重的读写互斥拆成了两条路径读走快照路径写走加锁路径。当读想看到最新提交状态并准备修改时就会主动走加锁路径这就引出了快照读和当前读的区分后面会细聊。先记住这个结论MVCC 是用版本空间换并发时间不是用无锁换并发。2. 版本链与ReadView多版本到底是怎么存出来的2.1 隐藏列与undo log每一行都背着历史包袱InnoDB 中聚簇索引的记录行不只存用户定义的列还会悄悄多出几个隐藏列DB_TRX_ID 表示最近一次修改这条记录的事务 IDDB_ROLL_PTR 指向该记录上一个版本的 undo log 记录。这俩是 MVCC 的地基。当一个事务更新某一行时InnoDB 会把修改前的旧值以及必要信息写入 undo log然后把数据行的 DB_ROLL_PTR 指到这条 undo 记录DB_TRX_ID 改成当前事务 ID。如果同一个事务对同一行改了多次undo 里就会串起一条版本链每次读的时候通过 DB_ROLL_PTR 从当前版本一路向前找旧版本。注意INSERT 的 undo 在事务提交后就可以扔掉因为新插入的行对任何其他事务来说只有提交后才能看到提交之后旧版本就没有存在意义了。但 UPDATE/DELETE 产生的 undo 必须留着因为可能有另一个事务的 ReadView 还需要沿着版本链读到修改前的数据。还有个细节值得记住DELETE 本质上也是一种 UPDATE只是在记录上打上删除标记delete bit真正的物理删除要等 purge 线程把历史版本清掉之后才执行。从这里能看出MVCC 的多版本并不是把历史版本全都放在数据页里而是尽量少动数据页把旧版本堆到 undo 里。这也为后面讲 undo 膨胀埋下伏笔。2.2 ReadView四个字段可见性判断的一套水位线有了版本链下一步问题就是某个版本对当前事务是否可见InnoDB 引入 ReadView 来回答这个问题。生成 ReadView 时会记录以下关键信息m_ids当前系统中所有活跃未提交的读写事务 ID 列表。min_trx_idm_ids 中最小的那个事务 ID。max_trx_id生成 ReadView 时系统即将分配的下一个事务 ID也就是在这个快照建立之后才可能出现的 ID 水位线。creator_trx_id创建这个 ReadView 的事务自己的 ID。判断规则我整理成表格这是理解 MVCC 的钥匙条件判断结果版本 trx_id creator_trx_id可见自己改的版本 trx_id min_trx_id可见事务已提交版本 trx_id max_trx_id不可见事务还没开始min_trx_id trx_id max_trx_id在 m_ids 中则不可见不在则可见看完规则你可能还觉得抽象我举个具体例子。假设事务 AID100插入一行并提交事务 BID200开启事务执行 SELECT生成 ReadView 时活跃事务还包括事务 CID300此时 min_trx_id200max_trx_id301creator_trx_id200。版本链上这行的 trx_id100因为 100 小于 min_trx_id说明事务 A 早已提交所以 B 能看到。紧接着事务 CID300UPDATE 了这行版本链头部 trx_id 变成 300300 在活跃事务列表 m_ids 中B 的 ReadView 判断这个新版本不可见于是沿链向下找最终返回 trx_id100 的旧版本。这就是瞬间快照的真相它并不是靠保存一份完整数据副本实现的而是靠跳过不可见版本、找到第一个可见版本实现的。2.3 别把MVCC理解成按时间回溯一个常见误解是多版本并发控制是靠时间戳实现的半个小时前的读应该看到半个小时前的数据。其实 InnoDB 完全不看墙钟时间它看的是事务 ID 的先后顺序以及事务是否提交。事务 ID 的分配顺序基本可以理解为事务开始顺序但提交顺序和开始顺序不一定一致所以谁先提交谁可见也不完全准确真正决定可见性的是生成 ReadView 那一刻的活跃事务集合。这种设计的好处是读操作无需等待其他事务提交就能立刻执行坏处也很明显如果一个事务一直不提交它会长期占着一个活跃位置把所有后续版本的可见性判断都拖住。很多数据库故障的本质就是有一个早已被遗忘的事务却还躺在活跃事务列表里让其余所有事务都得绕着它走。3. 快照读与当前读的边界为什么RR还躲不开幻读RC到底读什么3.1 两种读法最大的差异在是否加锁日常写的 SELECT 是快照读InnoDB 直接根据 ReadView 在版本链上挑选合适的版本返回整个过程不加任何行锁所以它不阻塞写写也不阻塞它。而 SELECT ... FOR UPDATE、SELECT ... FOR SHARE、UPDATE、DELETE、INSERT 这些语句属于当前读它们必须读取最新的已提交版本并且对读取到的记录加锁X 锁或 S 锁。当前读不会走版本链找旧版本不是它不能而是它必须拿最新的否则更新就会基于一个过期版本那叫丢失更新。举个实际案例两个事务同时读同一行都读到 val1然后都执行 UPDATE valval1如果都基于旧值计算最终结果会是 2 而不是 3。当前读加锁的意义就在于保证读到的值在计算期间不会被人改掉。这一点在写业务代码时特别重要很多人以为 MVCC 能保证一切一致性结果在并发扣库存时出了大问题。3.2 可重复读RR第一次快照读时ReadView就定终身MySQL 默认隔离级别是可重复读REPEATABLE READ简称 RR。在 RR 下InnoDB 的实现是事务中第一次执行快照读时生成 ReadView此后直到事务结束这个 ReadView 都不再变化。也就是说一旦你在这个事务里跑了第一个 SELECT你看到的数据库就定格在那个水位线上后续其他事务提交再多数据你事务内再跑多少次快照读看到的都是一样的结果。这里有个容易忽略的细节如果事务一开始执行的是 UPDATE当前读之后才做 SELECTReadView 的生成时机是第一次快照读不是事务开始。所以不要把 RR 理解成从头到尾都一样它实际上只是从第一次快照读开始快照结果不变。看一个例子session A:START TRANSACTION; SELECT * FROM t WHERE id1; -- 此时生成ReadView读到旧值session B:UPDATE t SET val100 WHERE id1; COMMIT;session A 继续SELECT * FROM t WHERE id1; -- 快照读依旧读到旧值 SELECT * FROM t WHERE id1 FOR UPDATE; -- 当前读读到新值100这个现象很反直觉但特别重要。很多业务在 RR 下用 SELECT FOR UPDATE 做并发校验依然能读到最新数据就是因为它绕过了 MVCC 走了当前读。如果你用普通 SELECT 去做条件判断再更新就容易出现基于过期快照的误判。3.3 读已提交RC每条语句一个新的ReadView读已提交READ COMMITTED简称 RC隔离级别下每个快照读语句执行时都会重新生成一个 ReadView所以其他事务提交的新数据在下一条 SELECT 中就能看到于是同一个事务内两次相同的查询可能得到不同结果这就是不可重复读。RC 下没有定终身的概念。很多云数据库默认使用 RC原因很直接并发高、事务短不想让旧视图拖累 undo 回收。如果你的核心诉求是同一事务内两次查询必须一致那才需要 RR。在业务选型时我通常建议先用 RC 起步除非有明确的一致性读取需求否则 RR 带来的历史版本保留成本可能比想象中高。3.4 幻读MVCC没堵住的洞要靠next-key lock来补MVCC 能保证快照读的一致性但幻读这个经典问题在 RR 下依然可能出没尤其是在当前读和插入交错出现的场景。例如一个事务反复执行 SELECT * FROM t WHERE create_date BETWEEN ... FOR UPDATE第一次查到 5 条另一个事务插入了一条符合条件的新数据并提交这个事务再执行同样的当前读会看到 6 条记录。前后两次读到的行集合不一样这就是幻读。InnoDB 在 RR 下用 next-key lock记录锁 间隙锁来压制幻读当某个事务对范围内的记录加锁时会把范围内的间隙也锁上其他事务无法在这个 gap 里插入新行从而保证当前读阶段性不出现幻读。但间隙锁开销不小而且很容易引发死锁特别是两个事务互相在对方间隙里插入数据时。所以理解 MVCC 边界时脑子里要时刻有两条线一条是版本链上的快照读一条是加锁的当前读。很多线上死锁都是把这两种读混在一起用出来的。4. InnoDB的MVCC不是孤军奋战undo log、purge线程与锁的三角关系4.1 两种undoinsert undo与update undo的寿命不一样InnoDB 把 undo 分成了两类insert undo 和 update undo。insert undo 专门服务于 INSERT 操作事务提交后任何 ReadView 都不会关心这个新版本因为新插入的行对别的活跃事务来说要么不可见未提交要么已经可见已提交都不需要再看所谓的插入前状态所以这条 undo 可以直接删除。update undo 服务于 UPDATE 和 DELETE承载着修改前的旧版本。只要系统中存在一个可能还需要读到旧版本的 ReadView它就不能被清掉。理解这个差别对排查 undo 膨胀至关重要如果数据库的 undo 表空间一直涨十有八九是 update undo 堆积。单纯的 INSERT 流量再大也不会造成历史版本堆积因为 insert undo 提交即焚。4.2 purge线程清理逻辑与history list lengthpurge 线程负责两件事把标记删除的记录真正物理删除回收不再需要的 undo log。判定一条 undo 是否不再需要取决于系统中最早的 ReadView 覆盖到哪里。如果一个长事务开启了一个 ReadView 后一直不提交从它的视角看所有在它之后产生的版本都是不可见的未来版本为了支持这个长事务之后继续沿版本链读数据库必须把这条版本链上所有旧版本都保留着purge 线程就不能往前走。这时 SHOW ENGINE INNODB STATUS 里的 History list length 这个数字会持续抬升undo 表空间占用只增不减。这个指标比表行数更能反映 MVCC 的健康度。健康实例的 History list length 通常很低一旦长期高于几十万甚至上百万那就说明有活跃事务挡住了清理。很多 DBA 巡检只看 QPS、慢查询忽略了这个指标结果磁盘被 undo 吃掉大半才后知后觉。4.3 长事务与空事务是undo膨胀最常见的推手很多应用喜欢在业务代码里手动 BEGIN然后查完不 COMMIT连接被连接池回收后事务还开着。更隐蔽的是那些只读连接一条 SELECT 执行完没有显式事务但如果连接设置了 autocommit0下一次 SELECT 仍然在同一个事务里ReadView 不断刷新倒还好最怕的是事务一直开着不提交把最老的活跃 ReadView 卡死在那里。真碰到这种情况单靠改代码不够得先定位到具体连接。可以快速找出活跃时间最长的业务事务SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_age_seconds, trx_mysql_thread_id, trx_query FROM information_schema.innodb_trx ORDER BY trx_started ASC LIMIT 10;trx_started 最早的往往就是那块最老的绊脚石。注意 information_schema.innodb_trx 里空事务的 trx_query 可能为 NULL因为它在等待下一条语句但 trx_started 已经暴露了它开启时间有多久。很多人习惯看 processlist 中的 Sleep 状态来判断有没有问题结果发现连接状态是 Sleep 就以为没事其实事务早就开启了这就是排查误区。4.4 一致性读对主从延迟和备份同样有影响MVCC 并不只影响在线查询。mysqldump --single-transaction 就是利用 InnoDB 的 MVCC 做全局一致性快照备份备份过程中如果有大量 DMLundo 要尽量保留完整版本备份实例的资源会被拖高。主从同步也一样从库应用 binlog 时如果同时有客户端在做长查询从库的 undo 也会堆积。理解了 MVCC 之后你会发现数据库里的每一样新功能几乎都在跟旧版本还能不能清掉这件事博弈。备份、同步、在线加索引、统计信息采集全都依赖于一致性读又全都受制于一致性读。所以一个健康稳定的数据库不只是 SQL 写得快更要管理好那些看不见的版本。5. 实战复盘一次慢查询与undo膨胀的排查过程5.1 现象磁盘涨了CPU没爆我接手过的一个线上 MySQL 实例表现很典型磁盘使用率每周增长几个百分点但 CPU、IO 都还算正常。业务方反馈某张经营分析表的统计结果越来越慢明明加过索引。这时候第一反应不应该是去看 SQL而是先看 undo 和事务。我执行 SHOW ENGINE INNODB STATUS发现 History list length 已经到几百万健康实例这个值应该很低。再查 information_schema.innodb_trx果然有一个 trx_started 已经超过 3 小时的连接状态是 RUNNING但 trx_query 为 NULL。这个连接不是正在跑 SQL而是开着事务等下一个请求——典型的连接池复用导致的僵死事务。5.2 定位到具体业务连接拿到 trx_mysql_thread_id 后到 performance_schema.threads 或者直接看 processlist 去找到对应连接。这里有个很容易踩的坑只看 processlist 中 Command 是 Sleep 就判断连接空闲实际上事务可能早就在第一次 SELECT 时就开启了连接虽然 Sleep事务并没有提交。正确做法是看 information_schema.innodb_trx 的 trx_started而不是看 processlist 的 Command。很多排查工具默认把Sleep 连接当成无害空闲连接过滤掉这在没有 MVCC 的模型下问题不大但在 InnoDB 下大错特错。空闲连接和空闲事务是两码事一个空闲连接可能是一个正在挡着全局 purge 的长事务。5.3 处理kill连接还是等它结束这种僵死事务如果业务没有闭环最优策略是先通知业务再评估是否要 kill。KILL 掉连接会回滚它持有的事务如果这个事务改过很多行回滚可能要一两分钟甚至更久期间实例会有瞬时压力。如果只是只读事务直接 kill 没什么心理负担。处理完之后还要让运维把这条 SQL 加入巡检每天跑一次SELECT trx_mysql_thread_id, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age FROM information_schema.innodb_trx WHERE trx_started NOW() - INTERVAL 5 MINUTE;超过 5 分钟的事务单独报警。别小看这条规则很多团队把阈值设为 1 小时等报警出来时 undo 可能已经吃掉几十 GB 了。5.4 从脏数据看MVCC参数undo表空间回收不是重启就能解决MySQL 8.0 默认支持 undo 表空间自动截断innodb_undo_log_truncate但自动回收有个大前提没有活跃的旧 ReadView 遮挡。所以单纯调大 undo 表空间治标不治本根子还是把业务事务缩短。更重要的是不要指望 MySQL 重启能把 undo 清掉。重启后 InnoDB 会根据 redo 恢复未提交事务也会重新加载 undo 表空间膨胀依旧。我见过有人用重启来缓解 MVCC 问题结果启动起来 History list length 原封不动白忙一场业务还平白多了一次不可用时间。6. 从MVCC看数据库的取舍InnoDB、PostgreSQL与其他实现的分野6.1 InnoDB原地更新 undo版本链InnoDB 的 MVCC 是基于旧版本放账外的思路数据页上的记录只保留最新值旧版本塞进 undo log。好处是数据页不会因为多次更新产生大量碎片索引维护相对简单聚簇索引不需要紧跟每个版本坏处是读一个旧版本要顺着 roll_pointer 链回放链越长回放越贵而且 undo 的清理与索引修改关系复杂。这也是为什么长事务在 MySQL 上比在 PostgreSQL 上更容易引发性能事故。一个几万条记录的版本链每次读取都可能要沿链走好多跳对热点行的访问可能从微秒级变成毫秒级。再加上 purge 线程如果跟不上版本链会进一步变长形成恶性循环。6.2 PostgreSQL新版本直接堆在数据页里靠vacuum回收PostgreSQL 走的是另一条路。它的堆表里更新时会生成一个新 tuple旧 tuple 仍然留在原数据页里通过行头字段 xmin/xmax 标记可见性范围。更新时旧 tuple 的 xmax 被标记为当前事务 ID新 tuple 的 xmin 等于当前事务 ID。读事务判断元组是否可见主要看 xmin/xmax 与自己的事务快照之间的对比。这样做的好处是读旧版本不需要回放 undo 链版本可见性判断通常更稳定坏处是数据页会被死 tuple 占满查询可能要扫描更多页所以需要 VACUUM 清理死 tuple 和更新可见性映射。PostgreSQL 的表膨胀问题本质上也是 MVCC 的代价。我整理一个快速对比表方便你记住两者差异维度InnoDBPostgreSQL多版本存储数据页放最新值旧版本写 undo log新旧版本都在数据页旧版本等待 vacuum读旧版本方式沿 undo 版本链回放直接读页内旧 tuple空间回收purge 线程清理 undovacuum 清理死 tuple长事务影响undo 膨胀、版本链变长死 tuple 堆积表膨胀索引影响索引基本不受影响索引项可能指向死 tuplevacuum 需要清理这对架构选型有现实意义如果业务写多读少、更新频繁PostgreSQL 的表膨胀可能要投入更多维护精力如果业务里大量长事务、事务不结束InnoDB 的 undo 膨胀又很致命。关键是要理解自家业务的事务形状而不是唯性能论。6.3 其他实现Oracle的UNDO与SQL Server的版本隔离Oracle 的读一致性也依赖 UNDO 段通过 SCN系统变更号构造一致性读版本和 InnoDB 的 undo 思路同源。SQL Server 默认的 READ COMMITTED 是锁定读但如果开启 READ_COMMITTED_SNAPSHOT读操作会读 tempdb 中的行版本这又是另一种取舍。这些实现五花八门但万变不离其宗要么保存旧版本要么生成新版本目的都是让读不被写阻塞。理解 MVCC 的时候先问清楚这个数据库维护的到底是旧版本还是新版本比背一堆参数更有用。6.4 千万别把MVCC当成免死金牌最后说点个人体会。MVCC 的确解决了读写互斥但它引入了新的维护成本undo、死 tuple、purge、vacuum、间隙锁、版本可见性判断。你在索引设计、SQL 优化、事务拆解上的每一个偷懒最终都可能被 MVCC 的放大效应反噬。所以每当我看到数据库性能报警脑子里不再只有加索引这个选项还会多问一句是不是有一个读视图挡着一切让数据库在替一个早已忘了提交的事务打工能回答好这个问题比记住 ReadView 的四个字段值钱得多。
