一文彻底弄懂mysql的事务日志，undo log 和 redo log

在数据库事务管理中，Undo Log 和 Redo Log 是两种关键日志，用于保障事务的 原子性 和 持久性。它们的作用是确保数据库在出现崩溃、断电、宕机等故障时，能够进行恢复操作，从而保障数据一致性和完整性。它们通常用于支持事务的 ACID 特性中的 原子性 和 持久性。下面将分别介绍 Undo Log 和 Redo Log 的原理、实现机制、以及它们的作用。

一、Undo Log

Undo Log 是回滚日志，它的作用是在事务发生异常或主动回滚时，用于撤销已执行的操作，确保数据库数据能够回到事务开始前的状态，保证事务的 原子性。

1. 工作原理

• 作用：Undo Log 记录了在事务执行过程中对数据的每次修改前的数据副本（即修改前的旧值），这些旧值在回滚时用于恢复到数据的原始状态。
• 事务开始时：事务执行过程中，每当进行写操作（如 INSERT、UPDATE、DELETE）时，数据库会将修改前的记录保存在 Undo Log 中。
• 回滚时：如果事务回滚，系统会通过 Undo Log 将这些记录回滚至修改之前的状态，从而实现撤销操作。

例如：

• 如果执行了一条 UPDATE 操作，事务会记录修改前的数据值。
• 如果事务最终失败或主动执行了回滚（ROLLBACK），数据库会使用 Undo Log 将被更新的数据恢复到原始值。

2. Undo Log 的实现

• 逻辑日志：Undo Log 是一种逻辑日志，记录的是逻辑上的修改操作。它并不会直接记录每次操作的物理存储修改，而是记录修改前的数据。

• 链表结构：InnoDB 存储引擎会为每条记录维护一条 Undo Log 记录，并以链表的方式串联起来。如果事务需要回滚，MySQL 会沿着 Undo Log 链表进行逐条回滚，直到恢复到事务开始时的状态。

• Undo Log 的类型

  ：

  • 对于 INSERT 操作，Undo Log 记录的是“删除”操作，因为如果事务回滚，需要撤销插入的数据。
  • 对于 DELETE 操作，Undo Log 记录的是“插入”操作，用来恢复被删除的数据。
  • 对于 UPDATE 操作，Undo Log 记录的是修改前的旧值，用来恢复原来的值。

3. 使用场景

• 事务回滚：当事务执行失败或用户显式要求回滚时，Undo Log 会将所有修改的数据恢复到事务开始前的状态。
• MVCC（多版本并发控制）：Undo Log 也用于实现 MVCC 机制。不同事务可能在不同时间看到不同版本的数据，这些版本的数据就是由 Undo Log 提供的。这样，未提交的事务修改对其他事务是不可见的，帮助实现隔离性。

4. 示例

假设有一条 UPDATE 语句：UPDATE user SET balance = balance + 100 WHERE id = 1;。在修改 balance 之前，数据库会将 id = 1 用户的原始 balance 值存储在 Undo Log 中。如果事务回滚，系统会从 Undo Log 中恢复 balance 的原始值。

二、Redo Log

Redo Log 是重做日志，主要用于恢复已经提交的事务，确保数据库的 持久性（Durability）。当数据库发生崩溃时，Redo Log 可以帮助恢复已经提交但尚未写入磁盘的数据。

1. 工作原理

• 作用：Redo Log 记录的是对数据库的物理层面的修改，确保当系统崩溃时，已经提交的事务所做的修改不会丢失。通过 Redo Log，MySQL 能够在崩溃后重做已提交事务的修改，保证事务的持久性。
• 事务提交时：当事务提交时，MySQL 并不会立即将所有数据刷新到磁盘（因为磁盘 IO 较慢），而是先将修改内容记录到 Redo Log 中，之后再异步地将数据写入磁盘。

例如：

• 在执行一条 INSERT、UPDATE 或 DELETE 操作时，数据库会先将修改记录写入 Redo Log。当事务提交时，系统会将 Redo Log 刷入磁盘，保证数据不会丢失。
• 即使数据库此时宕机，数据页尚未持久化，但因为有 Redo Log，系统可以在重启后重新应用日志，恢复已提交的事务。

2. Redo Log 的实现

• 物理日志：Redo Log 是物理日志，记录的是物理数据页的更改，而不是 SQL 操作或逻辑操作。它记录了数据库物理块的变更，比如某个数据页上某条记录的修改。
• WAL（Write-Ahead Logging）机制：InnoDB 采用 WAL 机制，即先写日志，再写磁盘。每次事务提交时，InnoDB 会将 Redo Log 先写入磁盘，而后再慢慢将实际修改的数据写入磁盘。
• 循环写机制：Redo Log 采用固定大小的循环写机制。当日志写满时，会从头开始重新写。因此，在系统运行时，InnoDB 会定期将日志应用到数据页，并将脏页（即被修改但还未写入磁盘的数据页）刷新到磁盘。

3. Redo Log 的使用场景

• 崩溃恢复：当数据库崩溃后，通过重启，MySQL 可以根据 Redo Log 恢复所有已提交的事务。这是 MySQL 保证事务持久性的关键机制。
• 提高性能：因为 Redo Log 可以先于数据页写入磁盘，数据库无需每次事务提交时都立即写入数据页，从而显著提高了写操作的性能。数据页的写入可以在稍后的时间由后台线程异步完成。

4. 示例

假设执行一条 UPDATE 语句：UPDATE user SET balance = balance + 100 WHERE id = 1;。当事务提交时，MySQL 会将修改后的 balance 值写入 Redo Log，并将 Redo Log 刷入磁盘。如果系统在修改完成后立刻崩溃，虽然数据页未刷新，但 MySQL 可以通过 Redo Log 在重启时恢复提交的事务。

三、Undo Log 和 Redo Log 的区别

四、总结

• Undo Log 保证了事务的 原子性 和 隔离性，在事务回滚和多版本并发控制（MVCC）中起到关键作用。
• Redo Log 保证了事务的 持久性，在系统崩溃后可以恢复已提交的事务操作，确保数据一致性。

在实际的业务系统中，Undo Log 和 Redo Log 是支撑 MySQL 数据库事务和恢复机制的基础。Undo Log 主要用于撤销未完成或回滚的事务操作，而 Redo Log 则用于保证已提交的事务在系统崩溃时能够得到恢复。