【MySQL】第8节｜Innodb底层原理与Mysql日志机制深入剖析（一）
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刷新）。
重要参数
| 参数名 | 说明 |
|
| 单个 redo log 文件大小，影响写入性能和恢复速度（增大可减少切换频率，但恢复时间更长）。 |
|
| 日志文件数量，默认 2 个（ |
|
| 控制 redo log 刷新到磁盘的时机（0/1/2，默认 1，保证事务持久性）。 |
与崩溃恢复的关系
当数据库宕机重启时，InnoDB 会执行以下步骤：
- 重做（Redo）：扫描 redo log，将已提交但未写入数据页的变更应用到数据页。
- 回滚（Undo）：利用 undo log 回滚未提交的事务（由事务原子性保证）。
- 示例：若事务 T 提交后 redo log 已写入磁盘，但数据页未更新时宕机，重启后通过 redo log 完成数据页更新，确保 T 的变更生效。
总结
redo log 是 InnoDB 实现事务持久化的核心机制，通过 顺序写日志+延迟更新数据页 的方式提升性能，同时保证数据不丢失。理解 redo log 有助于优化事务性能（如调整 innodb_flush_log_at_trx_commit）和诊断故障（如日志文件大小设置不合理导致频繁切换）。