MySQL 的 redo log（重做日志）

redo log 是 MySQL 中 InnoDB 存储引擎实现事务持久性的关键机制，用于记录数据库数据的变更，确保事务提交后数据不丢失，即使发生宕机也能通过日志恢复数据。

核心作用

1. 实现事务的持久性（Durability）

事务提交时，先将变更记录写入 redo log 并持久化到磁盘，再执行实际的数据页更新（可能延迟执行，即 WAL 机制，Write-Ahead Logging）。

• • 即使数据库崩溃，重启后可通过 redo log 恢复未写入数据页的变更，保证事务提交的结果不丢失。

2. 提升写入性能

数据页更新可能需要随机 IO（较慢），而 redo log 按顺序写入磁盘（顺序 IO，速度快），避免频繁直接操作数据页，提升事务提交效率。

关键概念

redo log 组成

• 重做日志文件（物理文件，如 ib_logfile0、ib_logfile1）：

固定大小、循环写入（类似环形缓冲区），默认大小约 48MB（可通过 innodb_log_file_size 配置）。

• 重做日志缓冲（redo log buffer，内存区域）：

事务执行过程中，变更先写入内存缓冲，提交时刷新到磁盘日志文件。

WAL 机制（Write-Ahead Logging）

事务提交时，先写 redo log 到磁盘，再更新数据页（可能延迟到 checkpoint 时执行）。

• • 示例：

执行 UPDATE user SET age=20 WHERE id=1 时：

• 生成 redo log 记录（记录“id=1 的行，age 从 18 变为 20”）。
• 将 redo log 写入内存缓冲。
• 事务提交时，将缓冲中的 redo log 刷新到磁盘日志文件（此时事务已提交，数据不丢失）。
• 数据页更新可能在后续由后台线程执行（buffer pool 刷新）。

重要参数

参数名	说明
innodb_log_file_size	单个 redo log 文件大小，影响写入性能和恢复速度（增大可减少切换频率，但恢复时间更长）。
innodb_log_files_in_group	日志文件数量，默认 2 个（ib_logfile0 和 ib_logfile1）。
innodb_flush_log_at_trx_commit	控制 redo log 刷新到磁盘的时机（0/1/2，默认 1，保证事务持久性）。

与崩溃恢复的关系

当数据库宕机重启时，InnoDB 会执行以下步骤：

1. 重做（Redo）：扫描 redo log，将已提交但未写入数据页的变更应用到数据页。
2. 回滚（Undo）：利用 undo log 回滚未提交的事务（由事务原子性保证）。
   • 示例：若事务 T 提交后 redo log 已写入磁盘，但数据页未更新时宕机，重启后通过 redo log 完成数据页更新，确保 T 的变更生效。

总结

redo log 是 InnoDB 实现事务持久化的核心机制，通过 顺序写日志+延迟更新数据页 的方式提升性能，同时保证数据不丢失。理解 redo log 有助于优化事务性能（如调整 innodb_flush_log_at_trx_commit）和诊断故障（如日志文件大小设置不合理导致频繁切换）。