在MySQL中 redolog undolog binlog 写入的场景，顺序

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

日志类型	作用层面	主要功能	存放位置
Redo Log	InnoDB 引擎层	记录“数据页的物理修改”	InnoDB 特有（ib_logfile）
Undo Log	InnoDB 引擎层	用于事务回滚 & MVCC	InnoDB 表空间中
Binlog	Server 层	记录所有事务的逻辑操作，用于主从复制、恢复	全局（MySQL Server）

---

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

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。

例如：

 

UPDATE account SET balance = balance - 100 WHERE id = 1;

Undo Log 记录：

 

原 balance = 1000 新 balance = 900

作用：

• 事务回滚时恢复旧值

• 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 为例：

---

💡 执行过程图

 

┌──────────────────────────────┐│ MySQL层 ││ (Server + InnoDB) │└──────────────────────────────┘│┌─────────────────┼────────────────┐│ │▼ ▼【内存 Buffer Pool】 【磁盘日志】│ │ 1️⃣ 生成Undo Log（旧值） Undo Log 写入表空间 2️⃣ 修改内存数据页（新值） 3️⃣ 写入Redo Log（记录物理变化） 4️⃣ 写入Binlog（记录逻辑变化） 5️⃣ Redo Log 标记 commit（提交事务）

---

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

阶段	操作	说明
①	写入 Undo Log	为后续回滚做准备
②	写入 Redo Log（prepare状态）	保证事务可恢复
③	写入 Binlog	记录逻辑操作（主从复制）
④	Redo Log 改为 commit状态	标记事务提交成功

---

✅ 双写机制 + 两阶段提交（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 的一致性 = 数据的最终一致性。

---

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

场景	依赖日志	恢复方式
系统宕机恢复	Redo Log	重做未刷盘的修改
事务回滚	Undo Log	回滚未提交的事务
主从复制 / 数据恢复	Binlog	重放逻辑操作

---

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

 

BEGIN; UPDATE account SET balance = balance - 100 WHERE id = 1; COMMIT;

执行过程：

步骤	操作	日志
1	执行 UPDATE	生成 Undo Log（记录旧值）
2	修改 Buffer Pool 数据	产生 Redo Log（prepare）
3	写 Binlog	记录逻辑 SQL
4	Redo Log commit	标记提交完成
5	数据异步刷盘	后台刷到磁盘（checkpoint）

---

🧠 六、总结记忆口诀

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

日志	层级	主要作用	写入顺序
Undo Log	InnoDB	回滚/快照	第1写
Redo Log	InnoDB	持久化恢复	第2写（prepare + commit）
Binlog	Server	主从复制/恢复	第3写

---