Redo Log、Undo Log与MVCC：MySQL事务机制详解

如果你做过一段时间后端开发，或者准备面试大厂，大概率绕不过这三组词：Redo Log、Undo Log、MVCC。很多人把它们当成孤立的知识点背，结果越背越乱——今天看懂了Redo，明天碰上MVCC又忘了版本链怎么串。我在处理生产事故和做性能调优的过程中逐渐意识到，这三个东西根本不是三个独立章节，而是同一套事务机制的三个零件。想真正看懂MySQL，得先把它们放在一张图里理解。

这篇文章就围绕“一条UPDATE语句从执行到提交、再到崩溃恢复”这条主线，把Redo Log、Undo Log和MVCC的关系拆开讲透。文章既包含原理推演，也会给出一线干活时用得上的参数配置、排查命令和踩坑记录。适合正在准备MySQL面试的开发者，也适合需要处理线上事务问题、想搞懂数据库内核逻辑的DBA或架构师。

老规矩，先说结论：Redo Log负责“持久性”，Undo Log负责“原子性”，MVCC配合Undo Log负责“隔离性”。但这只是表象，它们真正协作的细节，藏在内存、日志文件、隐藏列和一条条的版本链里。

1. 事务机制全景：一条UPDATE语句经历了什么

1.1 事务的四大特性从来不该被割裂着看

很多人把ACID背得很熟：原子性、一致性、隔离性、持久性。但一追问“这些特性具体由哪个模块实现的”，就开始含糊了。实际在InnoDB里，这个分工非常清晰：

理解这个分工后，很多面试题就通了。比如“为什么MySQL需要Redo Log，直接刷数据页不行吗”，本质上就是在问：随机写磁盘太慢，而WAL机制用顺序写日志换性能，再用日志保证数据不丢。

再比如“事务回滚是怎么实现的”，很多人以为是“内存里留了一份旧数据快照”，实际上InnoDB并没有为每个事务保存完整快照，它只是把每次修改前的旧版本记录在Undo Log里，需要回滚时沿着反向操作逐个恢复。这样设计的好处是节省空间，代价就是你得理解版本链。

1.2 一条UPDATE语句在内存和磁盘间经历了什么

我常用下面这个场景来解释整个流程。假设有一张订单表，你要执行：

sql复制UPDATE orders SET status = 'PAID' WHERE id = 100;

这条语句执行时，InnoDB大概会走这几步：

1. 从存储引擎中读取id=100的数据页，如果内存缓冲池（Buffer Pool）里没有，就先从磁盘加载进来。
2. 对这行记录加上排他锁，防止其他事务并发修改。
3. 把修改前的整行数据写入Undo Log（确切说是写入Undo表空间对应的内存缓冲区里），生成一个指向旧版本的指针。
4. 在内存中修改这行数据，同时生成一条Redo Log，记录“哪个页、哪个位置、发生了什么修改”。
5. 事务提交时，把Redo Log刷到磁盘。此时数据页本身可能还停留在内存里，并没有强制刷盘。
6. 后台线程在合适的时候，把脏页异步刷到磁盘。

你发现没有，真正的数据文件在提交那一刻可能完全没有被更新。这如果放在没有WAL机制的数据库里，就是一场灾难——客户端收到“提交成功”的响应，数据却还在内存里。一旦数据库突然宕机，内存数据全部丢失，磁盘上还是旧数据。

有了Redo Log，情况就完全不同了。提交时真正需要刷盘的，是这个顺序写的日志文件，而不是随机读写的业务数据文件。

1.3 为什么日志必须写在数据文件之前

WAL（Write-Ahead Logging，预写日志）是InnoDB的核心理念：先把修改行为记录到日志里，再修改数据文件。这个顺序不是DBA拍脑袋定的，而是有深刻原因的。

你可以把它类比成饭店后厨的工作流程。顾客点菜后，服务员先在小票上写下订单，后厨再根据小票做菜。如果某个菜做到一半发现食材不够，至少还能凭小票向顾客解释和补做。如果服务员不去记小票，全凭脑子记菜名，一旦传菜过程中打了个岔，后厨马上就乱套。

数据库也是同理。内存中修改数据页是一瞬间的事，但这个页随时可能被LRU算法淘汰出内存、被后台线程刷盘，或者因为掉电而消失。只有把修改行为固化成日志文件里的记录，才能保证在任何崩溃场景下，系统启动后都能重新执行这些修改。数据可以晚点写，但日志必须先落盘。

那Undo Log呢？它同样要走一遍内存和磁盘的路径，但它的角色更像是“悔棋记录”。改之前先存一份反向数据，将来出了任何问题，都能按这条记录退回原点。

2. Redo Log：崩溃恢复的底层担当

2.1 Redo Log记录的不是业务数据，而是页面的物理修改

首先要纠正一个很常见的误解：Redo Log里存的不可能是完整SQL。你执行一条UPDATE，如果Redo只记录“哪张表、哪行、改成什么”，那崩溃恢复时还得重新解析SQL、重新走一遍索引查找，不仅慢，而且同一个SQL在不同时间执行产生的物理影响未必一样。InnoDB很聪明，它在崩溃恢复时根本不需要知道业务逻辑，只需要知道“第5号数据页的偏移量1024处，应该写入什么值”。

所以Redo Log记录的内容通常被称为“物理逻辑日志”。所谓物理，是指它记录了具体的页号、偏移量；所谓逻辑，是指它不像二进制日志（Binlog）那样记录SQL语句，而是记录“在某个页的某个位置做什么操作”。

这里有个实操场景能帮你加深理解。假设你凌晨跑了一个批量更新，影响了10万行。这些行可能分布在1000个数据页里，每一页的修改都会生成若干条Redo Log。崩溃恢复时，InnoDB不需要再查一次这10万行数据，它只要按日志顺序，把对应的页重新改一遍即可。

2.2 日志缓冲与刷盘时机：innodb_flush_log_at_trx_commit的取舍

生产环境里，你最常配置的参数就是innodb_flush_log_at_trx_commit。这个参数控制的是事务提交时Redo Log刷盘的策略，同时也是面试中特别爱问的“为什么MySQL要双1”的答案所在。

它有三个取值：

我刚接手线上系统时，见过不少团队为了压接口耗时，偷偷把innodb_flush_log_at_trx_commit改成0或2。短期看确实能降低RT，但代价是出现宕机时可能丢失最近1秒内的全部已提交事务。对金融、订单类业务来说，这种优化无异于玩火。

如果你既想要安全、又想要性能，不要走这个歪门邪道，应该优先考虑下面几个方向：

• 使用SSD，随机写性能本身就比机械盘好很多。
• 开启Redo Log组提交（Group Commit），让多个事务的提交合并成一次日志刷盘。
• 合理控制单事务的大小，避免大事务长时间占用Redo Log空间的写入吞吐。

2.3 LSN与Checkpoint：日志如何做到循环覆盖

Redo Log不是无限增长的，它采用循环写入。InnoDB会通过LSN（Log Sequence Number，日志序列号）来标记写入位置和数据页的修改版本。

这里我不打算扯太多源码，只用一个乘电梯的比方帮你建立直觉。假设整栋电梯井就是Redo Log文件组，电梯不停从1楼上到顶楼，然后又回到1楼重新开始。乘客在某一层下电梯后，楼层会打上一个标记，表示“这层我已经访问过了”。数据库里的LSN就类似电梯当前所在楼层，Checkpoint则类似已经安全刷盘的位置。

每次数据页被修改时，页头上会记录一个LSN，表示“这个页已经更新到哪条日志了”。当Redo Log要覆盖旧空间时，InnoDB会检查最早那个尚未刷盘的脏页LSN，如果日志空间不够，就必须先把这些脏页刷到磁盘，推进Checkpoint位置。这就是为什么Redo Log文件如果配置得太小，往往会出现间歇性的磁盘写放大，而不是单纯的日志写满报错。

查看当前LSN和Checkpoint状态，可以用：

sql复制SHOW ENGINE INNODB STATUS;

输出里会有一段类似Log sequence number和Log flushed up to的信息，方便你判断日志写入和刷盘进度是否健康。

2.4 崩溃恢复时到底发生了什么

假设数据库在某个瞬间宕机了。重启后会不会丢数据，完全取决于Redo Log有没有持久化。整个过程分三步：

1. InnoDB会扫描最后一个Checkpoint记录的位置，这个位置之前的脏页都已经刷盘，无需处理。
2. 从Checkpoint之后开始扫描Redo Log，把其中记录的所有修改重新应用到对应的数据页上。这里要注意，崩溃时可能存在“日志成功写入，但事务还没来得及提交”的情况，这些未提交事务的修改也会在重放阶段被应用回数据页。
3. 重放结束后，再借助Undo Log，把那些“Redo存在但事务未提交”的修改回滚掉。

所以你可以把崩溃恢复理解成：先用Redo Log把数据库推到崩溃前一刻的最新状态，再用Undo Log把半截子事务抹掉。前者保证持久性，后者保证原子性。这也是为什么说Redo和Undo在恢复阶段是互相配合的，而不是非此即彼。

这里也有一个非常实用的排查经验：如果SHOW ENGINE INNODB STATUS里显示History list length持续增大，同时系统重启恢复时间变长，大概率是Undo Log没有被及时清理。这个问题我们在下一节展开。

3. Undo Log：从回滚到版本链

3.1 回滚的本质是执行反向操作

要说清Undo Log，我们得先把事务回滚的底层逻辑讲明白。

InnoDB的Undo Log分为两大类：insert undo log和update undo log。听名字就能猜出用途。插入一条新记录时，回滚操作简单，直接把这个插入删掉就行，所以insert undo log在事务提交后可以被立刻清理。而UPDATE或DELETE操作的回滚就要复杂得多，因为被修改的记录可能已经被其他事务读取了，所以update undo log不仅要支持回滚，还要配合MVCC提供旧版本数据。

以UPDATE为例，假设你要改一行数据：

sql复制UPDATE user SET age = 30 WHERE id = 1;

执行时，InnoDB并不是先把旧值拷贝一份放在某个地方，而是从磁盘或缓冲池里读出这行数据，先写一条Undo Log，这条日志里记录了类似“把id=1这行的age从20改回20所需的信息”。事务如果回滚，InnoDB会根据Undo Log里的信息，把这个页面的值从前映像恢复为后映像，用前映像的数据覆盖回来。

用“拍照”来类比，大多数人的第一反应是：每个事务开始前给整张表拍一张快照。这是不对的，InnoDB没有这个能力，也不该这么做。它做的是给每一行操作前的旧版本拍一张小照片，照片就存在Undo Log里去。

3.2 隐藏列和版本链：开启MVCC的钥匙

理解Undo Log只是基础，真正让InnoDB能实现高并发读的，是它记录在行数据里的隐藏列。InnoDB的聚簇索引记录中，包含两个关键隐藏列：

• DB_TRX_ID：最近一次修改该行记录的事务ID。
• DB_ROLL_PTR：指向该行记录上一个版本的Undo Log指针。

每次对某行执行UPDATE时，InnoDB会把当前版本的数据复制一份，写入Undo Log，然后让新版本的DB_ROLL_PTR指向这个旧版本。这样，一行数据在物理上存在多个版本，通过指针串成一条链表，也就是我们常说的“版本链”。

版本链的结构大概是：

code复制最新版本 <- DB_ROLL_PTR指向 <- 上一个版本 <- DB_ROLL_PTR指向 <- 再上一个版本

回到上面的SQL例子。事务T1把id=1的age从20改成30，版本链上就会出现两个版本：第一个版本age=20是T1修改前生成的Undo Log，第二个版本age=30是新版本行。如果再有一个事务T2把age改成40，版本链就变成三个版本。这条链子越长，说明一行数据被并发修改的次数越多。

3.3 事务隔离级别是如何依赖旧版本数据的

既然有版本链，那么“不同事务读到不同结果”就成了自然的结果。关键是每个事务要决定自己能看到哪个版本。这就是隔离级别在起作用。

读未提交（Read Uncommitted）隔离级别下，事务可以读到其他事务尚未提交的修改。这种读取不关心版本链，直接读最新版本即可。

读已提交（Read Committed）隔离级别下，事务只能读到其他事务已经提交的版本。如果它看到的行还是未提交事务修改的，就会顺着版本链继续往前找，直到找到一个事务ID满足已提交条件的版本。

可重复读（Repeatable Read）隔离级别下，事务第一次执行SELECT时会生成一个ReadView（一致性视图），之后整个事务期间都用同一个ReadView来判断可见性。这样即使其他事务已经提交了修改，它依然只认第一次生成视图时“可见”的版本。

串行化（Serializable）是最严格的隔离级别，它直接对读取的行加锁，冲突事务只能排队。这种场景下MVCC的优势被弱化，因为读操作不再是无锁读。

面试里经常有人把隔离级别和MVCC讲混，我建议你记住一个核心结论：MVCC不是用来实现所有隔离级别的，它只服务于“非锁定一致性读”，也就是普通SELECT。而不同隔离级别之间的差异，本质上就是生成ReadView的时机和频率不同。

3.4 Purge线程、长事务和Undo膨胀

既然旧版本要放在Undo Log里供MVCC读取，那么什么时候能清理这些旧版本？答案是：当没有任何活跃事务还需要用到它时。

Purge线程就是专门负责清理旧版本的。它会周期性地扫描Undo Log，把那些确实不再被任何事务引用的旧版本删除。这里最大的坑出现在长事务身上。想象一个事务在凌晨1点开启，但迟迟没提交，一直开到早上9点。这8个小时内，线上所有被修改过的数据，旧版本都不能被Purge线程清理，因为那个长事务的ReadView还“记着”那些旧版本。

我遇到过最夸张的一次，一个后台数据分析任务在事务里跑了两个小时，直接导致Undo表空间膨胀到几十GB，把磁盘差点塞满。后来检查发现，这个任务就是在一个@Transactional方法里做了大量的远程接口调用，事务无法及时提交，引发了连锁反应。

排查Undo膨胀时，建议优先查这三类信息：

sql复制-- 查看当前有哪些长事务在运行
SELECT * FROM information_schema.innodb_trx\G

-- 查看事务开始时间和已执行秒数
SELECT trx_id, trx_state, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_sec
FROM information_schema.innodb_trx;

只要发现有duration_sec大到离谱的事务，基本就能锁定问题。处理方式不是直接kill事务那么简单，还要优化业务代码，把事务边界缩小，把耗时操作从事务里拿出来。

4. MVCC：一致性的无锁读到底怎么工作

4.1 每一行记录都藏着“版本情报”

MVCC全称是Multi-Version Concurrency Control，多版本并发控制。它的设计目标很朴素：让读操作不要阻塞写操作，写操作也不要阻塞读操作。传统数据库用读写锁来实现并发控制，读和写互相排斥，并发能力自然上不去。InnoDB选择了一条不同的路：保留多个版本，让读操作去读旧版本，让写操作去改新版本，两者各玩各的。

每个版本背后，就是上一节说的隐藏列和版本链。不过光有版本链还不够，还得有一套规则，决定某个事务应该读取版本链上的哪一个版本。这套规则就是ReadView。

4.2 ReadView的核心判定逻辑

ReadView里最关键的信息包括：

• m_ids：生成ReadView时，当前系统中所有活跃（未提交）事务的ID列表。
• min_trx_id：m_ids中的最小值。
• max_trx_id：生成ReadView时，InnoDB分配给下一个新事务的ID。注意这个值不是“活跃事务中的最大值”，而是“最大活跃事务ID + 1”。
• creator_trx_id：生成这个ReadView的事务自己的ID。

假设某行的隐藏列DB_TRX_ID保存了它最近一次提交/修改的事务ID，那判断规则是：

1. 如果DB_TRX_ID等于creator_trx_id，说明这行是当前事务自己改的，当然可见。
2. 如果DB_TRX_ID小于min_trx_id，说明修改该行的事务在当前ReadView生成前就已经提交了，应该可见。
3. 如果DB_TRX_ID大于等于max_trx_id，说明这个版本是在当前ReadView生成之后才出现的，一定不可见。
4. 如果DB_TRX_ID介于min_trx_id和max_trx_id之间，需要进一步判断该事务ID是否还在m_ids列表中。如果在，说明它仍未提交，当前事务不可见；如果不在，说明它已经提交了，当前事务可以看见这个版本。

如果根据以上规则判定当前版本不可见，那就沿着DB_ROLL_PTR指向的Undo Log找上一个版本，再次执行同样的判断，直到找到可见版本或版本链耗尽为止。

这是面试重点中的重点。我建议你把这个逻辑手动跑几遍，画一个人口普查的图：先列一批事务，给每个事务分配ID，再按递增顺序提交，然后模拟一个SELECT，逐行判断能读到谁的数据。

4.3 Read Committed和Repeatable Read的ReadView差异

MVCC原理中有一道高频面试题：READ COMMITTED和REPEATABLE READ两种隔离级别下的差异是什么？答案就藏在“ReadView何时生成”里。

• READ COMMITTED：每次执行SELECT都会重新生成一个ReadView。
• REPEATABLE READ：只在第一次执行SELECT时生成ReadView，之后整个事务内都复用这个ReadView。

我用一个实际例子来说明。假设两张表各有一行数据：

sql复制CREATE TABLE test(
  id INT PRIMARY KEY,
  name VARCHAR(20)
);
INSERT INTO test VALUES (1, 'a');

两个事务按时间线执行：

• 在READ COMMITTED隔离级别下，T4时刻事务A的SELECT会生成新的ReadView，由于事务B已经提交，事务A会看到name='b'。这对应“不可重复读”问题。
• 在REPEATABLE READ隔离级别下，事务A在T2时刻生成的ReadView会一直用到事务结束。T4时刻即使事务B已经提交，事务A依然看不到name='b'，它读到的还是name='a'。

那么REPEATABLE READ又是怎么在快照读场景下防止“幻读”的？因为事务A的快照是固定的，其他事务插入的新行（事务ID等于或晚于ReadView中max_trx_id）在可见性判断时会被直接排除掉。所以同一个快照读执行两次，结果集完全一致，幻读从根源上被挡掉了。

4.4 当前读、加锁读和MVCC的边界

有人可能会问：既然MVCC这么强，那MySQL在REPEATABLE READ隔离级别下是不是就不会出现任何幻读了？不是。这里需要区分两类读操作。

快照读——普通SELECT，走MVCC，不加锁。REPEATABLE READ下不会出现幻读。

当前读——SELECT ... FOR UPDATE、SELECT ... FOR SHARE、INSERT、UPDATE、DELETE。这些操作必须读到数据的最新版本，还要对涉及的行加锁。它们根本不会去ReadView里慢慢判断，而是直接读当前已提交的最新版本。所以当前读在REPEATABLE READ下依然可能碰到幻读，比如两次SELECT ... FOR UPDATE中间，其他事务插入了一条新记录，第二次当前读就会多扫到一条。

为了处理当前读下的幻读问题，InnoDB还提供了间隙锁和临键锁（Next-Key Lock）。MVCC解决的是快照读的“看不到新值”，锁机制解决的是当前读的“同时修改并发插入”。两条路线合起来，才构成了完整的隔离性保障。

这里是一个非常容易踩坑的知识盲区。如果你开发的系统隔离级别是REPEATABLE READ，却在一个事务里反复使用SELECT ... FOR UPDATE做并发判断，不要以为MVCC能帮你挡住所有并发，最终防线还是加锁范围要设计精确。

5. 实战排查与调优经验

5.1 Redo、Undo、MVCC在问题排查时怎么配合

前面讲的都是理论，但如果你真到线上排查问题，会发现这三个知识点是互相咬合的。比如你查出一个长事务，它除了会导致Undo膨胀，还可能拖慢Purge线程，进而让版本链变得很长。而版本链一长，普通的SELECT执行“找可见版本”的代价也会增加，CPU消耗上升。这个问题最终会反馈到整体事务响应时间上。

我处理过类似案例：一个报表查询平时只要200毫秒，某天突然涨到5秒。一开始以为是SQL索引失效，后来通过information_schema.innodb_trx发现有一个跑了40多分钟的事务没有提交。这个事务期间线上有大量订单表更新操作，每个更新都留下一个不可清理的旧版本。报表查询每读一行，都要沿着版本链一直往前找，循环判断了40多分钟的事务版本是否符合可见性。等长事务提交后，查询性能立刻恢复。

这类问题的排查思路，建议按照下面的顺序来：

1. 确认是否存在长时间未提交的事务。
2. 查看这些事务锁定了哪些行，是否阻塞了其他事务。
3. 查看Undo表空间的使用率，判断是否已经膨胀。
4. 根据调用链反查代码，确认是不是把RPC、HTTP或批处理循环放进了事务里。
5. 修复代码后，把长事务相关的监控告警加上，比如事务执行时长超过30秒就告警。

5.2 常用观测命令和性能视图

这里放出我最常使用的一组排查SQL和命令，你可以直接保存下来当工具用。

查看当前所有事务及其状态：

sql复制SELECT trx_id, trx_state, trx_started,
       trx_mysql_thread_id, trx_query,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS run_seconds
FROM information_schema.innodb_trx;

查看InnoDB引擎整体状态，重点看LOG部分：

sql复制SHOW ENGINE INNODB STATUS;

输出内容中的关键字段含义如下：

查看Redo Log文件配置：

sql复制SHOW VARIABLES LIKE 'innodb_log%';

默认情况下，MySQL 5.7及以前用innodb_log_file_size控制每个Redo文件大小，innodb_log_files_in_group控制文件数量。8.0.30之后引入了innodb_redo_log_capacity，简化了容量管理。如果线上Redo Log配置偏小，你会看到日志写满后频繁触发脏页刷盘，SHOW ENGINE INNODB STATUS里的Log flushed up to长期贴着Log sequence number，但磁盘写入次数异常高。

5.3 Redo Log和Binlog为什么需要两阶段提交

聊事务日志时，很多人会把Redo Log和Binlog混在一起。实际上它们有本质区别。Redo Log是InnoDB存储引擎层的日志，记录物理页的修改；Binlog是MySQL Server层的日志，记录逻辑SQL或行变更，主要用于主从复制和数据恢复。

正因为它们在不同层，一个事务要同时写两套日志，就存在不一致风险。如果先写Binlog再写Redo Log，Redo恢复时可能丢了Binlog；如果先写Redo Log再写Binlog，主从同步时可能丢了Redo内容。MySQL的解决方式是内部的两阶段提交：事务执行时先写Redo Log并进入Prepare状态，再写Binlog，Binlog刷盘成功后再把Redo Log标记为Commit。

这个细节在崩溃恢复时尤其重要。如果Binlog已经写入成功，但Redo Log没有标记为Commit，MySQL会认为事务其实是成功的，并尝试让它提交，因为Binlog可能已经被同步到从库执行了；反过来的情况则会回滚。这也是为什么生产环境建议同时把：

ini复制innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

设置为1。双1配置从性能上看起来有开销，但它保证了MySQL在任何崩溃场景下，主从数据仍然能够保持一致。

5.4 参数调优的保守建议

从网上搜“MySQL性能优化”，能看到很多“把日志参数调到最大”的建议。我的观点是，在没搞清楚业务模型之前，激进调参都是危险的。给你一个相对保守的起步配置，可以在压测后逐步调整：

ini复制# 保证提交事务不丢失
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

# Redo Log容量控制在1~2GB左右，8.0.30及以上直接设置redo log容量
innodb_redo_log_capacity = 2G

# 脏页刷盘策略保持均衡，不要盲目设置为0
innodb_io_capacity = 5000

# 开启独立Undo表空间，避免和系统表空间挤在一起
innodb_undo_tablespaces = 2
innodb_undo_log_truncate = 1

注意，innodb_undo_tablespaces参数在8.0版本中已经调整为默认配置，无需手动维护，但在5.7里如果是从默认值修改，需要提前规划，因为该参数只能在初始化实例前修改或者重启后通过指定配置生效。

5.5 最后再分享一个容易被忽视的工具

线上如果频繁出现“事务锁等待超时”，不要急着调大innodb_lock_wait_timeout，先分析是不是长事务一直占用着某些行锁不释放。你可以用这条SQL快速查看阻塞关系：

sql复制SELECT
  r.trx_id AS waiting_trx_id,
  r.trx_mysql_thread_id AS waiting_thread,
  b.trx_id AS blocking_trx_id,
  b.trx_mysql_thread_id AS blocking_thread,
  TIMESTAMPDIFF(SECOND, b.trx_started, NOW()) AS blocking_duration
FROM performance_schema.data_lock_waits w
INNER JOIN information_schema.innodb_trx r
  ON w.REQUESTING_ENGINE_TRANSACTION_ID = r.trx_id
INNER JOIN information_schema.innodb_trx b
  ON w.BLOCKING_ENGINE_TRANSACTION_ID = b.trx_id;

定位到阻塞源头后，通常有两种处理：如果阻塞事务本身是无用的长事务，直接KILL它的线程ID；如果阻塞事务是正常高并发业务，就要考虑优化事务内SQL的顺序、缩短事务体量，或者改用更短的隔离级别。我曾经在一个库存扣减系统里遇到过，两个事务虽然改的是不同商品行，却因为一条范围查询加锁范围太大导致互相阻塞。最终改法是把这条SQL改成精准主键查询，并避免事务中一次更新过多行。

这些知识点串起来后，你会发现在MySQL里，Redo Log、Undo Log和MVCC从来不是孤立的。Redo保证了“你提交过的东西不会丢”，Undo保证了“你回滚的东西能原样退回去”，MVCC则让你在别人修改数据的同时，还能读到符合自己事务视角的旧版本。如果往深了说，它们每一个都还能再挖出很多源码细节，但从一线开发的视角看，先把这个三角关系装进脑子里，再去啃源码或者调参，才不会走偏。