一、Redo Log（重做日志）：InnoDB 事务持久性的保障
1. 核心作用
Redo Log 是 InnoDB 专属的物理日志（记录「数据页的修改内容」，如 "页号 X 的偏移量 Y 写入值 Z"），核心解决两大问题：
- 事务持久性：即使数据库崩溃，重启后可通过 redo log 恢复未刷盘的脏页数据，避免数据丢失；
- 减少磁盘 IO：先写 redo log（顺序写），再异步刷脏页到磁盘（随机写），提升写入性能。
2. 日志文件组
- Redo Log 由多个固定大小的物理文件组成（默认 ib_logfile0、ib_logfile1，可配置数量和大小），形成环形缓冲区（写满后覆盖旧日志，已刷盘的部分可覆盖）；
- 包含两个关键内存结构：
redo log buffer：内存缓冲区，事务执行时先写入此处，避免直接写磁盘；redo log file：磁盘文件，最终持久化的日志存储位置。
3. 刷盘时机（核心参数：innodb_flush_log_at_trx_commit）
该参数控制 redo log buffer 刷写到磁盘的时机，直接决定事务持久性，三种取值对应不同策略：
| 参数值 | 刷盘逻辑 | 持久性 | 性能 | 适用场景 |
|---|---|---|---|---|
| 0 | 每秒将 redo log buffer 刷到 os cache，再由操作系统异步刷到磁盘；事务提交时不做任何刷盘操作 | 最低（崩溃可能丢失 1 秒内数据） | 最高 | 非核心业务、允许少量数据丢失的场景 |
| 1（默认） | 事务提交时，强制将 redo log buffer 刷到磁盘（调用 fsync () 确保落盘） | 最高（符合 ACID 持久性） | 最低 | 核心业务、要求数据零丢失的场景（如金融、支付） |
| 2 | 事务提交时，将 redo log buffer 刷到 os cache；操作系统每秒异步刷到磁盘 | 中等（崩溃仅丢失 os cache 中未刷盘的数据） | 中 | 兼顾性能与持久性的通用场景 |
补充：无论参数取值如何，InnoDB 后台线程会每秒刷一次 redo log buffer 到磁盘，避免数据积压。
4. 关键特性
- 顺序写：redo log 文件是环形顺序写入，比随机写数据页效率高 10 倍以上；
- 物理日志：仅记录数据页的修改，不记录 SQL 逻辑，恢复速度快；
- 崩溃恢复：数据库重启时，InnoDB 会重做 redo log 中未刷到数据文件的修改，保证数据一致性。
二、Binlog（二进制日志）：MySQL 服务器层的逻辑日志
1. 核心作用
Binlog 是 MySQL 服务器层的逻辑日志（记录「SQL 执行的逻辑」，如 "给 id=1 的行的 name 字段赋值为'张三'"），与存储引擎无关（MyISAM/InnoDB 均支持），核心用途：
- 主从复制：主库将 binlog 发送给从库，从库重放日志实现数据同步；
- 数据恢复：通过
mysqlbinlog工具解析 binlog，恢复指定时间段的数据； - 审计：记录所有数据修改操作，便于追溯操作记录。
2. 记录格式
Binlog 支持三种格式，各有适用场景：
STATEMENT（基于语句）：记录执行的 SQL 语句，日志体积小，但对「非确定性 SQL」（如含 NOW ()、UUID ()、自增列）可能导致主从不一致；ROW（基于行，默认）：记录行的修改前后状态（如 "id=1 的行，name 从'李四'改为'张三'"），主从一致性最高，日志体积稍大；MIXED（混合模式）：自动选择 STATEMENT/ROW，兼顾体积与一致性。
3. 写入机制
- Binlog 是「事务提交时写入」：事务执行过程中，修改操作先缓存，事务提交时一次性写入 binlog（按事务顺序写入，保证事务原子性）；
- 刷盘参数：
sync_binlog（默认 1），取值 1 时事务提交强制刷盘，0 时由操作系统异步刷盘，N 时每 N 个事务刷一次盘。
4. 与 Redo Log 的两阶段提交（核心关联）
为保证 binlog 和 redo log 的数据一致性（避免主从数据不一致），InnoDB 事务提交采用「两阶段提交」：
- 准备阶段（prepare） ：
- 事务执行完成，InnoDB 将 redo log 刷盘（状态标记为 prepare）；
- 此时 redo log 已持久化，但 binlog 尚未写入。
- 提交阶段（commit） ：
- MySQL 服务器层将 binlog 刷盘；
- 通知 InnoDB 将 redo log 状态标记为 commit，事务完成。
崩溃恢复逻辑：
- 若崩溃发生在 prepare 后、commit 前：重启后检查 binlog，若 binlog 完整则提交事务，若不完整则回滚事务；
- 两阶段提交核心目标：保证 redo log 和 binlog 要么都成功，要么都失败，避免数据不一致。
三、Undo Log（回滚日志）：事务原子性与 MVCC 的支撑
1. 核心作用
Undo Log 是 InnoDB 专属的逻辑日志（记录「数据修改前的状态」），核心功能：
- 事务回滚：事务执行出错时，通过 undo log 恢复数据到修改前的状态，保证事务原子性；
- 实现 MVCC（多版本并发控制）：读取数据时，通过 undo log 构建历史版本，实现读不加锁（快照读）。
2. 核心特性
- 逻辑日志：记录行修改的反向操作（如插入行则记录删除，更新行则记录回滚到旧值）；
- 版本链：每行数据的多个版本通过 undo log 形成版本链，配合事务 ID 实现快照读；
- 回收机制：undo log 并非永久保存，当没有事务需要访问某个版本时，后台线程会异步回收；
- 存储位置：Undo Log 存储在 InnoDB 的 undo 表空间（默认共享表空间，可配置独立表空间）。
3. 与 Redo Log 的区别
| 维度 | Redo Log | Undo Log |
|---|---|---|
| 作用 | 重做修改，保证持久性 | 回滚修改，保证原子性 / MVCC |
| 日志类型 | 物理日志（数据页修改） | 逻辑日志（行修改的反向操作） |
| 生命周期 | 刷盘后可覆盖（环形） | 事务提交后保留，按需回收 |
| 写入时机 | 事务执行中持续写入 | 事务执行时随数据修改写入 |
四、三大日志核心关联与小结
1. 核心关联逻辑
2. 总结
- Redo Log ：InnoDB 物理日志，通过
innodb_flush_log_at_trx_commit控制刷盘时机，保障事务持久性，是崩溃恢复的核心； - Binlog：服务器层逻辑日志，支持三种记录格式，主从复制 / 数据恢复的核心，与 redo log 配合通过「两阶段提交」保证一致性；
- Undo Log：InnoDB 逻辑日志，支撑事务回滚和 MVCC，是读不加锁的关键，生命周期随事务版本访问情况动态回收；
- 三大日志分工明确：redo log 保 "持久"，binlog 保 "同步 / 恢复"，undo log 保 "原子性 / 并发"，共同支撑 MySQL 事务的 ACID 特性。
3. 核心参数
| 日志类型 | 核心参数 | 关键作用 |
|---|---|---|
| Redo Log | innodb_flush_log_at_trx_commit | 控制事务提交时 redo log 的刷盘策略 |
| Binlog | sync_binlog + binlog_format | 控制 binlog 刷盘时机和记录格式 |
| Undo Log | innodb_undo_tablespaces + innodb_purge_threads | 控制 undo 表空间和回收线程 |