MVCC（多版本并发控制）与可见版本

热身 · 一 为什么需要旧值 · 二 版本怎样留下 · 三 读视图 · 四 沿链判断 · 五 两种级别 · 六 保留与边界 · 七 应用 · 检验 · 表达 · 追问 · 隔日复测

学完能做到什么，为什么现在学

给定一条数据的版本链、Read View（读视图）建立时的活跃事务名单和两个编号边界，你能从最新版本开始逐个判断，找出本次普通查询实际返回的值；还能解释为什么换一个读视图，结果可能不同。

第11课已经讲过两种常用隔离级别下的读数，以及重复审批不应继续修改。本课继续回答背后的“为什么”：不是只记可重复读会读旧值，而是把旧值从哪里来、怎样找到它讲清楚。本课属于 MySQL 事务专题，不需要先学 JVM（Java 虚拟机）。

前置： 知道事务何时提交，以及普通查询和锁定查询不同。 必学： 第一至七节、选择题与表达。第三节后可暂停，保持完整一课。只讨论普通一致性读和已有记录的更新；锁范围、死锁处理另讲，源码字段名及删除边界放拓展。

主读： 官方 InnoDB（事务存储引擎） Multi-Versioning（多版本存储）。先读开头两段、DB_TRX_ID（最近修改事务编号）与 DB_ROLL_PTR（回滚指针）的说明，再读“更新撤销信息何时可丢弃”。不要先背字段字节数。内部判断另核对了 mysql-8.4.0 标签的源码，链接见文末来源[4][5]。

学完正文后，可以对照本课末尾的课后问答，重点看视图何时更换、上边界怎样判断，以及为什么查询完成后要及时结束事务。

热身：回忆前几课（3分钟）

先凭记忆说一句，再展开核对。答不上来就记下来，接着往下学，这不是进入新课的门槛。

一、已经被修改了，为什么还能读到原来的值

“别人已经提交新数据，我的普通查询为什么还能返回旧数据？”

继续用办件表，但这次只看1201号办件的经办人。列 id 是办件编号，owner_id 是经办人编号。1201号原来由7号经办人负责，后来改成9、11、13。这些编号都是教学设定，只用来演示人员变化。

如果每次更新都彻底抹掉旧内容，A想按早先的快照查询时，旧值就无处可找。InnoDB（事务存储引擎）因此保存还原旧内容所需的信息：新查询可以读新版本，早先的普通查询可以按规则找到旧版本。这就是 MVCC（多版本并发控制）要支持的工作。[1]

整个过程有两件事，缺一不可： 先有办法还原以前的行，再决定这次查询允许看哪个版本。 只有旧数据而没有可见性规则，仍可能读到别人未提交的修改；只有规则而没保留旧信息，又无法返回旧值。

二、先把一行数据的修改过程连起来

“版本链是什么？撤销日志只用于回滚吗？”

先把两个编号分清： 办件编号1201标识业务记录，写事务编号103标识一次修改者 。不同事务可以先后修改同一办件。事务编号不等于经办人编号，也不能按它直接推断提交先后。

以下是本课的完整时间顺序。A只读、不改数据，使用 REPEATABLE READ（可重复读），且一直保持同一显式事务。100号事务一直在修改另一条不相关记录，不碰1201；其他未列出的编号不影响结果。[2]

注意④的先后：105先提交，112才修改同一行。本例没有让两个未结束写事务同时改同一行。第三节会把③建立的读视图具体展开。

行里留下什么线索

对这里的聚簇索引记录，DB_TRX_ID（最近修改事务编号）告诉数据库“这个行版本是谁修改的”；DB_ROLL_PTR（回滚指针）指向相应的 undo log（撤销日志）记录。undo log（撤销日志）包含撤销最近修改、还原旧行所需的信息，既能用于事务回滚，也能用于一致性读还原旧版本。[1][3]

到了步骤⑤，可以把重建过程画成下面这条 version chain（版本链）：

这是逻辑上的还原过程，不是说每一行完整副本都单独存放一份。 为了A读到9，需要保留能还原到9的信息；它不要求7永远留着。本课实际查找到9就会停止。

三、读视图：记住建立时，哪些修改还不能看

“有很多旧版本，数据库凭什么决定读哪一个？”

Read View（读视图）是一次可见性判断所用的信息集合。它记录建立时仍活跃的读写事务，以及编号边界等信息。这里“活跃”表示还没结束，修改不能被其他普通一致性读当成已提交结果。只读A没有修改1201，本例先专注其他事务的版本。[5]

在第二节步骤③，假设读视图捕获了下面这份信息。编号是教学设定，允许中间有未展示的事务，不要求连续。

为什么名单里有100，而1201从没被100修改？因为读视图不只为这一行制作，它要能判断查询遇到的其他记录。因此不能把活跃名单当成“这条版本链上的作者名单”。

判断一个版本，依次做什么

先看它是否为本事务自己的修改。若是，自己的修改可见；若不是，使用下面三步。规则与固定版本源码的判断相符。[4]

1. 修改者编号小于100： 对本例正在检查的有效行版本，可见。
2. 修改者编号大于或等于110： 不可见。它超出了读视图建立时允许看到的编号范围。
3. 编号在100到109之间： 再查建立时的名单。在名单里，不可见；不在名单里，可见。

拿103举例：它比100大，并不意味着不可见；它又小于110，且不在当时的活跃名单中，所以其已提交的版本可见。拿105举例：它在名单里，当时未完成，所以对这个读视图不可见。 看的是建立时的名单，不是查询这一刻重新问一遍“你现在提交了吗”。

可以在这里暂停。先能解释103为什么可见、105为什么不可见，再沿整条版本链走一遍。

四、完整走一遍：13、11、9，最后为什么停在9

“A第二次查的时候，105和112都提交了，为什么还可能读到9？”

继续第二节步骤⑤，A复用步骤③的读视图：下边界100、上边界110、活跃名单100和105；A没有自己的写入。当前版本链是112写13→105写11→103写9。注意这些版本 现在 都已提交，但可见性仍按A原来的视图判断。

105后来提交，不会把它从A已有的名单中动态删掉。否则A第一次读到9，第二次就可能因为105提交而读到11，失去同一快照的读取规则。[2][4]

因此两种常见误解都要避开： 不是找“当前已经提交的最新值”，也不是找“最老的值” 。准确过程是从新向旧，找到第一个对本次读视图可见的版本，然后返回。

五、两种隔离级别：变的是视图的使用时机

“读已提交和可重复读的底层规则，是不是完全不同？”

在这里讨论的普通一致性读中，都需要判断版本可见性。核心区别是 何时建立、是否复用读视图 ：READ COMMITTED（读已提交）每次一致性读使用新的快照；REPEATABLE READ（可重复读）在同一事务内复用首次一致性读建立的快照。[2]

现在把主例只改一个条件：A使用 READ COMMITTED（读已提交）。105未提交时，A第一次查询仍读到9。后来105、112依次提交，A第二次查询建立新的读视图。假设此时100仍活跃、其他事务均结束，新的上边界为113：

同一组修改，读数不同的原因就在这张表里。旧视图不接受后来完成的105，新视图在105已经完成后建立，所以不再把105列为活跃；当前112也已经提交并落在新视图可见范围中。

再回忆第11课：普通 START TRANSACTION（开始事务语句）不等于立刻建立读取快照。本课说的是 首次普通一致性读 的时点；开始时显式请求一致性快照的特殊语句另有规则。自己的写入也仍可见，不能把“读旧版本”理解成永远忽略自己刚改的内容。[2]

六、旧版本不能马上删，也不能用来代替加锁

“事务已经提交，为什么还要留撤销信息？一直开着只读事务有什么影响？”

105提交后，自己的回滚需求结束了，但A还可能需要把11还原成9。因此，支持这些旧快照所必需的 update undo（更新撤销信息）不能仅因写事务提交就马上删除。只有不再被相关读取或回滚需要时，才具备清理条件；purge（历史清理）在后台处理可清理的历史，并不保证一提交就立即完成。[1][6]

假设A一直不结束原来的可重复读事务，其他人不断修改。A可能仍需要早先的版本，相关历史就无法及时清理，历史积压和空间占用可能增长。 只读不等于没有代价 ，问题是它长期保留了旧视图。不能把事务开着去等待用户操作；查询完成后应及时结束事务。[1][6]

这与重复审批的保护是另一件事。snapshot read（快照读）回答“我现在可以看哪个版本”，不负责阻止其他人修改。SELECT … FOR UPDATE（查询并加更新锁）这样的 locking read（锁定读），要按最新可用记录和锁规则处理，不能直接用本课旧视图版本链决定审批资格。第11课已经讲过：取得保护后再核对状态。回看第11课。

七、完整应用：给你一份新视图，自己沿链找

“换一组数字，还能把每一步判断讲出来吗？”

这是一道独立教学题，不延续主例的编号。 A只读，在同一 REPEATABLE READ（可重复读）事务里复用旧视图；下边界200、上边界210、建立时的活跃名单为200和205。没有自己的修改、没有删除、没有结构变更。下面是另一条办件记录从新到旧的有效版本链，当前所列写事务均已提交；其中205在视图建立时尚未提交。

1. A返回哪个经办人编号？逐项解释212、205、203，不只给最终数字。
2. 如果另一次普通查询使用新视图，名单只有200、下边界200、上边界213，版本链不变，返回谁？

-- 准备：连接B，事务演示开始之前
CREATE TABLE teach_mvcc_0012 (
  id BIGINT PRIMARY KEY,
  owner_id INT NOT NULL
) ENGINE=InnoDB;
INSERT INTO teach_mvcc_0012 VALUES (1201, 9);

-- ① 连接B：改成11，但先不提交
START TRANSACTION;
UPDATE teach_mvcc_0012 SET owner_id = 11 WHERE id = 1201;

-- ② 切到连接A：第一次普通查询，此刻建立读视图
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT owner_id FROM teach_mvcc_0012 WHERE id = 1201;
-- 预期9，不是尚未提交的11

-- ③ 切回连接B：先提交11，再开启另一次事务改成13
COMMIT;
START TRANSACTION;
UPDATE teach_mvcc_0012 SET owner_id = 13 WHERE id = 1201;
COMMIT;

-- ④ 切回连接A：仍是原事务
SELECT owner_id FROM teach_mvcc_0012 WHERE id = 1201;
-- 预期仍为9
COMMIT;
SELECT owner_id FROM teach_mvcc_0012 WHERE id = 1201;
-- 新事务查询预期13

八、即时检验：合上正文，做一次

每题给出所需前提，点击后立即反馈。只做一次，再进入表达，不靠重刷猜答案。

1. 本课已有行被更新后，普通查询需要还原原来的值，主要使用什么信息？

• A. 为各事务复制的全表
• B. 修改留下的撤销信息
• C. 备份系统的整库备份

2. A无自己的写入。旧视图下边界100、上边界110、建立时活跃名单100和105。已有行的有效更新版本链为112写13→105写11→103写9，现在都已提交，无删除。A返回哪个值？

• A. 十三号经办人
• B. 十一号经办人
• C. 第九号经办人

3. 105在A旧视图建立时尚未提交，后来已经提交。A仍复用原视图、自己不写。对105版本怎样判断？

• A. 仍按建立时名单判断
• B. 按当前提交状态判断
• C. 自动改用最新的名单

4. A无自己的写入，视图上边界为110。另一事务编号恰好是110，后来写出一个版本并提交。这个旧视图能看该版本吗？

• A. 已经提交所以可见
• B. 达到上界仍不可见
• C. 等于上界直接可见

5. A自己不写，在同一读已提交事务中第一次普通查询读到9；随后105提交经办人11，再由112改成13并提交。没有其他修改或删除，A第二次普通查询为什么能读到13？

• A. 原有视图名单被修改
• B. 原有版本记录全删除
• C. 本次读取使用新视图

6. 写事务已经提交，但另一个长事务的旧视图仍需要相关旧值。支持重建的更新撤销信息能马上全部丢弃吗？

• A. 仍被旧视图需要须保留
• B. 写事务一提交全部删除
• C. 只读事务不会用旧信息

九、用完整回答检验理解

先独立回答四问。可以写下来，也可以先口述再整理成文字；每一问都明确范围，不需要猜未给出的业务处理规则。

1. 1201号的经办人从9改成11后，数据库凭什么还能还原9？分别说明当前行、修改者编号、回滚指针与撤销信息的作用。
2. A只读并复用旧视图，下边界100、上边界110、建立时名单100和105；已有行的有效更新版本链112写13→105写11→103写9，无删除。现在写事务都已提交。逐步说明三个版本为什么被跳过或选中，最终返回哪个经办人？
3. A在同一事务中只做普通查询、自己不写：第一次读到9，随后其他事务依次把经办人改成11、13并提交，没有其他变化。若A分别使用读已提交、可重复读，第二次各返回什么？说明两种级别何时建立或复用视图。
4. 一段报表查询代码在可重复读下第一次查询后，仍把事务开着等待用户确认十分钟，同时其他人不断修改记录。可能拖住什么？应该怎样调整事务结束时机？这是一道设计题。

练习：请在自己的笔记中写出答案（也可附第七节逐步推演），再回到第二至六节的“可以这样答”核对。

可选的双连接实验不是继续学习的前提；能跟着讲解读懂、能独立讲出来、隔几天仍能答对，是三件不同的事。

十、集中追问：只问前面讲过的内容

先自己答，再展开

十一、隔日复测：换编号，保留判断方法

建议隔一天用5分钟回答；约一周后再换数据重做。刚看过答案就能复述，不等于已经记牢。

主来源与引用

本课速查。数字是教学设定；手工推演、源码核对和实际数据库运行结果要分开看。

1. 多版本存储：隐藏字段、旧版本重建、更新撤销信息保留，以及二级索引的可见性检查。

2. 一致性非锁定读：两种级别的快照时机、自己的写入例外、普通读与其他操作的边界。

3. 撤销日志：还原最近修改与一致性读取旧数据。

4. mysql-8.4.0：ReadView::changes_visible（版本可见性判断）：创建者、两边界与活跃名单判断。

5. mysql-8.4.0：ReadView::prepare（准备读视图）：捕获名单与编号边界。

6. 历史清理：后台清理条件、长事务对历史积压的影响。本课不要求调整清理参数。

学完后，换一组编号自己沿版本链走一遍，记下仍不确定的那一步，例如“105已经提交，为什么还不能返回11”，再回到第三、四节核对。锁住哪些记录、为什么等待，放在第13课讲。

课后问答：理解是怎样变化的

问题与结论默认可见。展开后可看理解过程；以下根据真实交流整理，并非逐字稿。

已有行被改过几次后，普通查询怎样找回旧值？主例中103写出的版本为什么可见？

最终结论： 沿回滚指针找到撤销信息，逐步还原更早的行版本。103可见的完整理由是：它处于下边界100与上边界110之间，且不在读视图建立时的活跃名单中。

A在同一个显式事务里自己不写：第一次普通查询读到9，随后其他事务依次把值改成11、13并提交。A第二次普通查询，读已提交和可重复读各返回什么？

最终结论： 读已提交：第二次使用本次新建的视图，返回13。可重复读：第二次复用首次普通读的旧视图，返回9。换不换视图取决于隔离级别和“是否又一次普通一致性读”，不取决于A自己是否提交。

Read View（读视图）里保存的是上一次的查询结果吗？

最终结论： 不是。读视图保存的是选择版本所需的判断信息（建立时的活跃名单、编号边界、创建者），不是装着查询结果的盒子。

A的旧视图上边界是110。另一个事务的编号恰好是110，后来修改了这行并提交。A复用旧视图、自己不写，能看到这个版本吗？

最终结论： 看不到。对其他事务写出的版本，编号大于或等于上边界110就不可见，无论它后来是否提交。

报表在可重复读事务中查完后，事务一直开着等用户操作十分钟，同时别人不断修改数据，会有什么问题？应该怎样调整？

最终结论： 报表查询完成后及时结束这次只读事务，把结果交给页面，等待用户操作期间不占着旧事务。之后若要写入，开启适当的新事务并重新核对必要状态。