1. Redo Log（重做日志）
- 作用：主要用于崩溃恢复，确保事务的持久性（Durability）。当数据库异常重启时，通过重放redo log将未刷盘的脏页恢复到最新状态。
- 物理/逻辑：记录的是物理日志，描述数据页的具体修改（例如页号、偏移量等）。
- 写入方式：顺序写入，采用循环覆盖模式（固定空间，写满后覆盖旧日志）。
- 写入时机：
- 事务执行过程中，修改操作会先写入内存的redo log buffer。
- 提交事务时强制刷盘（innodb_flush_log_at_trx_commit=1时）。
- 其他情况如buffer占用过半或后台线程定期刷盘。
- 其他特性：
- 与undo log关联：undo log的修改也会生成redo log，确保undo log的持久性。
- 两阶段提交：事务提交时，redo log先标记为prepare状态，binlog写入后再标记为commit。
2. Undo Log（撤销日志）
- 作用：主要用于事务回滚和 MVCC（多版本并发控制） ，实现原子性（Atomicity）。记录事务修改前的数据状态，用于逆向操作。
- 物理/逻辑：属于逻辑日志，记录与操作相反的逻辑（如INSERT对应DELETE）。
- 写入方式：随机读写，存储于回滚段（rollback segment）中。
- 持久性保障：依赖redo log保护，undo log的修改会伴随redo log的生成。
- 应用场景：
- 事务回滚时，根据undo log逆向恢复数据。
- MVCC中提供历史版本数据，支持一致性读。
3. Bin Log（二进制日志）
- 作用：用于数据归档、主从复制和时间点恢复。记录所有对数据库的修改操作（包括非事务引擎的操作）。
- 物理/逻辑：属于逻辑日志，记录SQL语句或行变更的逻辑操作（如UPDATE语句）。
- 写入方式：追加写入，保存全量日志，不会覆盖旧记录。
- 写入时机：事务提交后一次性写入（sync_binlog参数控制刷盘策略）。
- 与事务的关系：
- 所有存储引擎的修改均会记录。
- 在两阶段提交中，binlog写入是事务提交的关键步骤，确保redo log与binlog的一致性。
三者的核心区别与联系
| 特性 |
Redo Log |
Undo Log |
Bin Log |
| 作用 |
崩溃恢复，持久性 |
事务回滚，MVCC |
数据归档，主从复制 |
| 日志类型 |
物理日志（页修改） |
逻辑日志（逆向操作） |
逻辑日志（SQL或行变更） |
| 存储引擎 |
InnoDB特有 |
InnoDB特有 |
MySQL Server层，所有引擎可用 |
| 写入方式 |
循环写入 |
随机读写 |
追加写入 |
| 持久性依赖 |
独立持久化 |
依赖redo log保护 |
独立持久化 |
| 事务提交阶段 |
两阶段提交（prepare/commit） |
事务执行时生成 |
事务提交后写入 |
Comments NOTHING