Mysql三大日志写入时机

---

### **1. Redo Log（重做日志）**

- **作用**：

- **持久性保障**：记录事务对数据的修改操作（如插入、更新），用于系统崩溃后的数据恢复。

- **事务提交后的持久化**：即使事务未完全提交，Redo Log 的部分信息已写入磁盘，确保崩溃后可恢复。

- **写入时机**：

1. **事务开始时**：Redo Log 缓冲区被分配。

2. **数据页修改时**：将修改操作写入 Redo Log 缓冲区（`buffer pool`）。

3. **事务提交时**（取决于 `
innodb_flush_log_at_trx_commit` 配置）：

- **`=1`（默认）**：立即将 Redo Log 刷新到磁盘。

- **`=0`**：仅将 Redo Log 写入缓冲区，可能在后续刷新。

- **`=2`**：提交时将 Redo Log 刷新到磁盘，但不立即同步。

- **恢复作用**：在崩溃恢复时，通过 Redo Log 重新执行未提交的修改（保证持久性）。

---

### **2. Undo Log（撤销日志）**

- **作用**：

- **事务回滚**：记录事务的逆向操作，用于回滚未提交的事务。

- **MVCC（多版本并发控制）**：为快照读提供历史数据版本。

- **写入时机**：

1. **事务开始前**：为每个事务分配一个独立的 Undo Log 段。

2. **数据页修改时**：生成对应的 Undo Log 记录（逆向操作）。

- **插入操作**：记录删除原数据。

- **更新操作**：记录旧值。

- **删除操作**：记录被删除的数据。

3. **事务提交时**：

- **临时 Undo Log**：事务提交后，Undo Log 可能被标记为可重用（非永久保留）。

- **永久 Undo Log**：对于长事务或大事务，部分 Undo Log 需持久化到磁盘。

- **恢复作用**：在崩溃恢复时，通过 Undo Log 回滚未提交的事务（保证原子性）。

---

### **3. Binlog（二进制日志）**

- **作用**：

- **主从复制**：记录所有 DDL 和 DML 操作，从节点通过 Binlog 同步数据。

- **数据恢复**：支持基于时间点的恢复（如 `mysqlbinlog` 工具）。

- **写入时机**：

1. **事务开始时**：Binlog 缓冲区被分配。

2. **事务中的 DML/DQL 操作**：将操作记录写入 Binlog 缓冲区。

3. **事务提交时**：

- **强制写入磁盘**：Binlog 缓冲区的内容被刷新到磁盘文件（`mysql-bin.log`）。

- **提交顺序**：在事务提交时，**Binlog 必须完全写入磁盘后才能返回成功**，否则可能导致主从数据不一致。

- **恢复作用**：通过 Binlog 应用所有操作，将数据库恢复到一致状态。

---

### **三者的写入顺序与协作**

#### **事务提交流程（简化版）**

1. **执行 DML 操作**：

- 修改内存中的数据页（`buffer pool`）。

- 生成 **Undo Log**（逆向操作）并写入缓冲区。

- 生成 **Redo Log**（正向操作）并写入缓冲区。

2. **事务提交（`COMMIT`）**：

- **Redo Log 刷新**（取决于 `
innodb_flush_log_at_trx_commit`）：

- 若配置为 `1`，Redo Log 缓冲区被强制写入磁盘。

- **Binlog 刷新**：

- Binlog 缓冲区的内容被写入磁盘，**必须完成此操作后事务才算提交**。

- **提交事务**：

- 释放锁资源。

- 标记 Undo Log 为可重用（临时 Undo）或持久化（永久 Undo）。

#### **关键顺序**

- **Binlog 写入必须在 Redo Log 刷新之后**？

不一定。实际上，Binlog 的写入独立于 Redo Log，但为了保证原子性，**Binlog 必须完整写入磁盘后事务才提交**。若 Binlog 写入失败，整个事务会被回滚（通过 Undo Log）。

#### **崩溃恢复逻辑**

1. **Redo Log**：

- 恢复所有已提交但未持久化的 Redo 日志（保证持久性）。

2. **Undo Log**：

- 回滚未提交的事务（保证原子性）。

3. **Binlog**：

- 应用所有 Binlog 事件，将数据库恢复到最新状态。

---

### **总结**

| 日志类型 | 主要作用 | 写入时机 | 依赖关系 |

|----------------|------------------------------|-----------------------------------|------------------------|

| **Redo Log** | 持久性、崩溃恢复 | 事务修改时写入缓冲区，提交时可选刷新 | 与 Undo Log 协作恢复数据 |

| **Undo Log** | 回滚、MVCC | 事务修改时生成，提交时可部分持久化 | 与 Redo Log 配合恢复原子性 |

| **Binlog** | 复制、时间点恢复 | 事务提交时必须刷新到磁盘 | 独立于 Redo/Undo Log |

---

### **关键点**

1. **原子性保障**：

Binlog 写入是事务提交的最后一步。若 Binlog 写入失败，整个事务会被回滚（通过 Undo Log）。

2. **持久性保障**：

Redo Log 的刷新策略（`
innodb_flush_log_at_trx_commit`）直接影响数据持久性级别。

3. **恢复逻辑**：

Redo Log 和 Undo Log 共同保证事务的原子性和持久性，Binlog 则用于全量恢复和复制。