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

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

一、Undo Log

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

1. 工作原理

  • 作用:Undo Log 记录了在事务执行过程中对数据的每次修改前的数据副本(即修改前的旧值),这些旧值在回滚时用于恢复到数据的原始状态。
  • 事务开始时:事务执行过程中,每当进行写操作(如 INSERTUPDATEDELETE)时,数据库会将修改前的记录保存在 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 中,之后再异步地将数据写入磁盘。

例如:

  • 在执行一条 INSERTUPDATEDELETE 操作时,数据库会先将修改记录写入 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 Redo Log
作用 记录数据的旧值,用于回滚事务 记录数据的修改,用于恢复已提交的事务
日志类型 逻辑日志,记录逻辑操作 物理日志,记录数据页的物理修改
实现机制 链表结构,逐条回滚 固定大小的循环写机制,WAL 策略
使用场景 事务回滚、多版本并发控制(MVCC) 崩溃恢复、保证数据持久性
何时写入磁盘 修改数据时记录,但无需立即写入磁盘 事务提交时必须写入磁盘
涉及的 ACID 特性 原子性、隔离性 持久性

四、总结

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

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