🧩 一、三个日志的基本概念

🧠 二、三种日志的用途和作用详解

1️⃣ Redo Log（重做日志）

目的：保证事务的持久性（D of ACID）

当事务执行 UPDATE/INSERT/DELETE 时，InnoDB 不会立即把数据页刷盘，
而是：

1. 把修改写入内存缓冲区（Buffer Pool）

2. 同时记录一条 Redo Log（物理变化）

3. Redo Log 先写入磁盘（WAL，Write-Ahead Logging）

👉 即使宕机，只要 Redo Log 存在，系统重启后也能根据日志“重放”修改。

特点：

• 是物理日志（记录页号、偏移量、修改内容）

• 循环写（固定大小的日志文件组）

• 用于 崩溃恢复

2️⃣ Undo Log（回滚日志）

目的：保证事务的原子性（A of ACID）
当事务执行修改时，会先生成一份 “修改前的数据镜像”，即 Undo Log。

例如：

Undo Log 记录：

作用：

• 事务回滚时恢复旧值

• MVCC（多版本并发控制）读数据时使用历史版本（快照读）

特点：

• 是逻辑日志（记录反向操作）

• 存储在 InnoDB 表空间中（undo tablespace）

• 事务提交后，Undo Log 会被标记为可回收

3️⃣ Binlog（二进制日志）

目的：保证数据的可复制性和可恢复性

由 MySQL Server 层维护，记录了所有事务的逻辑操作（如 SQL 或行变化）。

作用：

• 主从复制：Slave 根据 Binlog 重放数据

• Point-in-Time 恢复：利用 Binlog + 全量备份恢复任意时刻数据

特点：

• 是逻辑日志（记录 SQL 或行级变化）

• 顺序追加写

• 与存储引擎无关（InnoDB、MyISAM 都会产生）

⚙️ 三、日志写入的顺序（重点）

当一个事务执行时，MySQL 涉及到 redo log、undo log、binlog 三者的交互。
以事务执行 UPDATE 为例：

💡 执行过程图

📜 实际写入顺序（事务提交阶段）

✅ 双写机制 + 两阶段提交（2PC）

因为 Redo Log 在引擎层、Binlog 在 Server 层，
为了保证 主从一致性，InnoDB 实现了“两阶段提交”：

🔹 阶段 1：prepare 阶段

• 写 Redo Log（状态为 prepare）

• 保证即使崩溃，也能恢复到 prepare 状态

🔹 阶段 2：commit 阶段

• 写 Binlog 成功后，再将 Redo Log 标记为 commit

💡 为什么要这样？

• 如果 Binlog 写成功但 Redo Log 未提交 → 数据丢失，主从不一致

• 如果 Redo Log 提交但 Binlog 未写成功 → 主从不一致

所以“两阶段提交”保证了：

redo log 与 binlog 的一致性 = 数据的最终一致性。

🧾 四、三个日志的恢复逻辑总结

🔍 五、示例演示事务执行全过程

执行过程：

🧠 六、总结记忆口诀

Undo 保原样，Redo 保结果，Binlog 保过程。