redo log是InnoDB实现持久性的核心，通过WAL先写日志再改数据，确保提交事务不丢失；其顺序写入和循环利用提升IO效率，崩溃时重做日志恢复未刷盘的脏页，保障数据一致性。
MySQL 中的事务日志，即 redo log（重做日志），是 InnoDB 存储引擎实现持久性和崩溃恢复的核心机制之一。它确保了即使在数据库意外宕机的情况下，已提交的事务也不会丢失数据。
redo log 的基本作用
redo log 记录的是“物理级别”的修改，也就是对数据页的具体更改操作，例如“在某数据页的某个偏移量处写入了某些字节”。它的主要目标是：保证事务的持久性（Durability），即一旦事务提交，其修改就能永久保存，即使系统崩溃也能恢复。
InnoDB 使用一种叫作 Write-Ahead Logging（WAL，预写日志） 的策略：所有对数据的修改必须先写入 redo log，然后再更新内存中的数据页（脏页），实际的数据文件（磁盘上的 .ibd 文件）可以稍后由后台线程异步刷盘。
redo log 的工作流程
当一个事务执行并提交时，redo log 按照以下步骤工作：
- 事务开始修改数据：InnoDB 先将数据页加载到内存（Buffer Pool），然后在内存中修改它。
- 生成 redo 日志条目：同时，InnoDB 将该修改操作记录到 redo log buffer（内存中的日志缓冲区）。
- 事务提交时写入磁盘：在事务提交时，redo log buffer 中对应的日志会通过 fsync 操作被强制写入到磁盘上的 redo log 文件（通常为 ib_logfile0 和 ib_logfile1）。
- 后续刷脏页：被修改的数据页（脏页）则由后台线程在合适时机刷回到磁盘数据文件中，这个过程可以延迟。
这种机制的好处是：磁盘 I/O 更高效。redo log 是顺序追加写入，比随机写数据文件快得多。而数据页的刷新可以批量、异步进行，不阻塞事务提交。
redo log 的结构与循环写入
redo log 文件是一组固定大小的文件，构成一个逻辑上的环形缓冲区。例如，如果有两个 1GB 的日志文件，总容量为 2GB，写满后会从头开始覆盖。
但不能无限制覆盖，因为某些老的日志对应的数据页可能还没刷回磁盘。InnoDB 使用一个叫 checkpoint 的机制来跟踪哪些 redo log 已经“不再需要”用于恢复。
简单来说：只有当对应的脏页被刷入磁盘后，其对应的 redo log 才能被覆盖。这样就保证了崩溃恢复时有足够的日志可用。
崩溃恢复时 redo log 的作用
如果 MySQL 崩溃重启，InnoDB 会自动进行恢复：
- 读取 redo log 中未确认完成刷盘的事务操作。
- 重新应用这些操作（即“重做”），将数据页恢复到崩溃前已提交的状态。
- 确保所有已提交事务的修改都反映在数据文件中。
这个过程对用户完全透明，是 MySQL 实现 ACID 中 D（持久性）的关键支撑。
基本上就这些。redo log 不复杂但容易忽略，理解它有助于掌握 MySQL 的底层可靠性机制。
