数据库（以 MySQL 为例）中，undo log、redo log 和 bin log 是三种重要的日志机制，它们各自有不同的作用和特点。以下是它们的区别和功能，简洁清晰地说明：
1. Undo Log
-
作用: 用于事务的回滚和一致性读（MVCC，多版本并发控制）。
-
功能:
- 记录事务执行前的数据旧值，以便在事务失败或回滚时恢复到原始状态。
- 支持 MVCC，提供事务隔离性（如读未提交、读已提交等），让不同事务读取一致的数据快照。
-
存储位置: 通常存储在数据库的回滚段（rollback segment）中，属于 InnoDB 存储引擎的日志。
-
特点:
- 逻辑日志，记录的是数据的逻辑操作（如“修改前是 A，修改后是 B”）。
- 仅在事务提交前有效，提交后可能会被清理（视 MVCC 需求）。
-
使用场景: 事务回滚、崩溃恢复、一致性读。
2. Redo Log
-
作用: 用于崩溃恢复，确保事务的持久性（Durability，ACID 中的 D）。
-
功能:
- 记录事务对数据的物理修改（如“在某个页面修改某条记录”）。
- 在事务提交时，将修改写入 redo log，确保即使系统崩溃，数据也能恢复。
-
存储位置: 存储在磁盘的物理日志文件中（如 InnoDB 的 ib_logfile），属于 InnoDB 存储引擎。
-
特点:
- 物理日志（或物理-逻辑日志），记录页面级别的修改。
- 顺序写入，性能较高。
- 提交事务后，redo log 会持久化到磁盘。
-
使用场景: 数据库崩溃后恢复已提交事务的修改。
3. Bin Log
-
作用: 用于主从复制和数据恢复。
-
功能:
- 记录所有对数据库的逻辑修改操作（如 INSERT、UPDATE、DELETE 的 SQL 语句或基于行的更改）。
- 用于主从同步（主库将 bin log 传输到从库，保持数据一致）。
- 可用于点-in-time 恢复（结合备份恢复到特定时间点）。
-
存储位置: 存储在磁盘的二进制日志文件中（如 mysql-bin.000001），属于 MySQL Server 层，非特定存储引擎。
-
特点:
- 逻辑日志，记录的是 SQL 或行级修改。
- 与存储引擎无关，适用于所有支持 bin log 的引擎。
- 可配置为 statement-based、row-based 或 mixed 格式。
-
使用场景: 主从复制、数据备份与恢复。
对比总结
| 特性 | Undo Log | Redo Log | Bin Log |
|---|---|---|---|
| 所属层 | InnoDB 存储引擎 | InnoDB 存储引擎 | MySQL Server 层 |
| 日志类型 | 逻辑日志 | 物理日志（或物理-逻辑） | 逻辑日志 |
| 主要作用 | 事务回滚、一致性读 | 崩溃恢复、持久性 | 主从复制、数据恢复 |
| 记录内容 | 数据修改前的旧值 | 数据修改的页面级操作 | SQL 语句或行级修改 |
| 存储位置 | 回滚段（内存+磁盘） | 物理日志文件（磁盘） | 二进制日志文件（磁盘） |
| 持久性 | 提交后可能清理 | 持久化到磁盘 | 持久化到磁盘 |
| 使用场景 | 事务回滚、MVCC | 崩溃恢复 | 主从同步、点-in-time 恢复 |
简单例子
假设执行 UPDATE table SET col = 10 WHERE id = 1：
- Undo Log: 记录 id=1 的旧值（如 col=5），用于回滚或 MVCC。
- Redo Log: 记录页面中 col 从 5 改为 10 的物理修改，用于崩溃恢复。
- Bin Log: 记录 UPDATE 语句或行数据修改，用于主从复制或恢复。
