undo log 的作用？(MVCC 历史版本 + 事务回滚)

考察要点

这道题面试官想看你是否深刻理解 InnoDB 存储引擎的两大核心功能：事务的原子性（通过回滚实现）和隔离性（通过 MVCC 实现）。同时，也考察你是否清楚 undo log 在其中扮演的具体角色、其数据结构、以及与 redo log 的协作关系，这体现了你对数据库内核原理的掌握深度。

核心概念

Undo log（回滚日志）是 InnoDB 存储引擎实现事务特性的关键组件之一，它是一种逻辑日志，记录的是数据被修改前的“旧值”，或者说是执行修改操作的“逆操作”。其核心作用有两个：事务回滚和多版本并发控制（MVCC）。

1. 作用一：事务回滚（实现原子性）

当用户执行 ROLLBACK 命令，或者数据库因异常（如死锁、断电）需要中断一个未提交的事务时，InnoDB 会利用 undo log 来撤销该事务所做的所有修改，将数据恢复到事务开始前的状态，从而保证事务的原子性（Atomicity）。

示例： 假设有一个账户表 accounts，初始数据如下：

一个事务执行了更新操作：

 1START TRANSACTION;
 2UPDATE accounts SET balance = 900 WHERE id = 1;

在执行 UPDATE 时，InnoDB 会执行以下步骤：

1. 记录 undo log：在修改数据页之前，先记录一条 undo log，内容大致为：“对于主键 id=1 的行，将其 balance 从 900 恢复到 1000”。
2. 修改数据页：在内存中的数据页（Buffer Pool）上，将 balance 修改为 900。

如果此时执行 ROLLBACK;，InnoDB 就会找到该事务对应的 undo log，并执行其逆操作，将 balance 恢复为 1000。

2. 作用二：多版本并发控制（MVCC，实现隔离性）

MVCC 是 InnoDB 用来实现读已提交（Read Committed）和可重复读（Repeatable Read）隔离级别的核心机制。它使得在同一时刻，不同的事务可以“看到”不同版本的数据行，从而避免了读写操作之间的相互阻塞。Undo log 在这里充当了历史版本的存储介质。

实现原理： InnoDB 在每行数据中都隐藏了两个关键字段：

• DB_TRX_ID (6字节): 最后一次修改（插入或更新）该行的事务 ID。
• DB_ROLL_PTR (7字节): 指向该行上一个版本的 undo log 记录的指针（回滚指针）。

当一个事务更新一行数据时：

1. InnoDB 会将原始行数据（旧版本）完整复制到 undo log 中。
2. 修改当前行的数据，并将该行的 DB_TRX_ID 更新为当前事务的 ID。
3. 将该行的 DB_ROLL_PTR 指向刚刚创建的 undo log 记录。

这样，一行数据的多个历史版本就通过 DB_ROLL_PTR 形成了一个版本链（Version Chain）。

 1graph LR
 2    subgraph 数据行 (最新版本)
 3        A["id=1, balance=800<br>DB_TRX_ID=102<br>DB_ROLL_PTR=ptr_to_undo_v2"]
 4    end
 5    subgraph Undo Log
 6        B["undo_v2: balance=900<br>DB_TRX_ID=101<br>DB_ROLL_PTR=ptr_to_undo_v1"]
 7        C["undo_v1: balance=1000<br>DB_TRX_ID=100<br>DB_ROLL_PTR=NULL"]
 8    end
 9    A -- "上一个版本" --> B
10    B -- "更早的版本" --> C

当一个事务（我们称之为事务 T）需要读取某行数据时，它会创建一个Read View（读视图）。Read View 决定了哪些事务版本对当前事务 T 可见。T 会从最新的数据行版本开始，沿着版本链进行判断：

• 如果当前版本的 DB_TRX_ID 对 T 可见，则直接读取该版本。
• 如果不可见，则通过 DB_ROLL_PTR 找到上一个版本的 undo log，再用这个历史版本的数据和它的 DB_TRX_ID 进行可见性判断。
• 重复此过程，直到找到一个可见的版本，或者版本链结束。

3. Undo Log 的管理

• 存储位置：在 MySQL 5.7 及之前，undo log 默认存储在系统表空间（ibdata1）中。从 MySQL 5.7 开始，可以配置独立的 undo tablespace (innodb_undo_tablespaces)，MySQL 8.0 则默认并推荐使用独立 undo 表空间。
• 清理机制：当一个 undo log 记录不再被任何活跃的事务（作为历史版本）需要时，它就可以被清理。这个清理工作由后台的 Purge 线程负责。如果存在长时间运行的事务，会导致大量的 undo log 无法被及时清理，从而造成 undo 表空间膨胀。

4. Undo Log 与 Redo Log 的区别

常见低分回答

1. 混淆 undo log 和 redo log：错误地认为 undo log 用于崩溃恢复。“如果服务器挂了，undo log 可以用来恢复数据”，这是 redo log 的作用。
2. 只知其一不知其二：只回答“undo log 用于事务回滚”，完全没有提及它在 MVCC 中提供数据历史版本的核心作用。这是一个重大失分点，说明对 InnoDB 的隔离性实现缺乏理解。
3. 对 MVCC 的解释含糊不清：说“undo log 能实现隔离”，但无法解释版本链、DB_ROLL_PTR、Read View 等关键概念，说明理解停留在表面。
4. 认为 undo log 是物理日志：描述成“undo log 就是把修改前的数据页完整备份一份”，这不准确。Undo log 是逻辑日志，记录的是恢复数据所需的信息，通常比物理页备份要小得多。
5. 忽略清理机制：不了解 undo log 是如何被回收的，也想不到长事务会导致 undo log 膨胀的问题，这表明缺乏生产环境的运维经验。

工程实践与优化

• 监控长事务：长事务是 undo log 空间膨胀的罪魁祸首。通过 information_schema.INNODB_TRX 表可以查询当前运行的事务及其持续时间，应重点监控 trx_started 时间过长的事务。
  sql

  ⧉⛶

   1SELECT trx_id, trx_state, trx_started, trx_query 
   2FROM information_schema.INNODB_TRX 
   3ORDER BY trx_started ASC;

• Undo 表空间配置：在 MySQL 8.0+ 中，默认使用 2 个独立的 undo 表空间。可以配置 innodb_undo_tablespaces 数量，并将它们放在高速 I/O 设备上。MySQL 8.0.14 之后支持在线收缩 undo 表空间（innodb_undo_log_truncate），有助于解决空间膨胀问题。
• 避免大事务：对于需要修改大量数据的操作（如数据清理、批量更新），应将其拆分为多个小事务分批执行。这不仅可以降低锁的粒度和持有时间，还能有效控制 undo log 的生成量，防止其快速膨胀并给 Purge 线程带来压力。
• Purge 线程调优：如果系统写入压力大，Purge 速度跟不上 undo log 生成速度，会导致性能问题。可以适当增加 innodb_purge_threads 的数量（默认为 4），以加快回收速度。

常见追问与延伸题目

1. 追问：你提到了长事务会导致 undo log 膨胀，在生产环境中如何发现并处理长事务？

   • 回答要点 1 (发现)：首先，通过监控系统设置告警，比如 Prometheus 监控 information_schema.INNODB_TRX 中事务的最长持续时间。其次，DBA 可以定期巡检，执行 SHOW ENGINE INNODB STATUS 查看 TRANSACTIONS 部分，或者直接查询 information_schema.INNODB_TRX。
   • 回答要点 2 (处理)：定位到长事务后，需要分析其来源。如果是应用 bug 或不合理的业务逻辑，需通知开发人员修复。如果是手动执行的查询忘记提交，应立即 COMMIT 或 ROLLBACK。如果是紧急情况导致数据库性能严重下降，可以联系业务方确认后，使用 KILL <thread_id> 命令终止该事务，但这会导致该事务已做的所有修改被回滚，产生额外的 I/O 开销。

2. 追问：undo log 和 binlog 有什么区别和联系？

   • 回答要点 1 (区别)：
     • 层面不同：undo log 是 InnoDB 存储引擎层的日志；binlog 是 MySQL Server 层的日志，所有存储引擎都可以使用。
     • 作用不同：undo log 用于保证事务的原子性和实现 MVCC；binlog 用于数据复制（主从同步）和时间点恢复（Point-in-Time Recovery）。
     • 内容不同：undo log 是逻辑日志，记录数据修改前的旧值；binlog 记录的是对数据库的逻辑修改操作（如 ROW 格式下记录行的变更内容），是“重做”日志。
   • 回答要点 2 (联系)：在事务提交时，两者通过**两阶段提交（2PC）**协议保持一致性。事务提交时，InnoDB 先将 redo log 置为 prepare 状态，然后写入 binlog，成功后再将 redo log 置为 commit 状态。这确保了只有在备库可以拉取到 binlog 的事务，主库崩溃恢复后也一定能恢复，保证了主从数据的一致性。

3. 追问：PostgreSQL 的 MVCC 实现和 MySQL 有什么不同？

   • 回答要点 1 (MySQL/InnoDB)：采用的是“在写时创建新版本”的思路，但旧版本数据存储在外部的 undo log 中。UPDATE 是原地更新（in-place update），即直接在数据页上修改最新版本的数据，旧版本被移到 undo log。清理工作由后台 Purge 线程异步完成。
   • 回答要点 2 (PostgreSQL)：采用的是“追加更新”的思路。UPDATE 操作实际上是一个 DELETE + INSERT。它不会修改旧的数据行（Tuple），而是将旧行标记为“已过期”（设置 xmax 事务ID），然后在表的堆空间中插入一个新行。这意味着新旧版本数据都存放在表本身。清理过期行（Dead Tuples）的工作由 VACUUM 进程负责。这种方式的优点是读历史版本很快（无需访问额外空间），缺点是可能导致表膨胀（bloat），需要依赖 VACUUM 及时回收空间。