binlog redolog undolog

binlog、redo log、undo log 是 MySQL 中三种关键日志，分别承担不同的功能，以下是它们的核心区别与作用：

---

1. binlog（二进制日志）

• 定义与层次：
  MySQL Server 层的日志，记录所有数据库的写操作（如 INSERT、UPDATE、DELETE），不包含查询操作。
• 类型与内容：
  • 逻辑日志：记录 SQL 语句的原始逻辑（如“修改某行数据”），而非具体数据页的物理修改。
  • 包含事务的开始、提交、回滚标记，支持主从复制和数据恢复。
• 写入方式：
  追加写，日志文件按顺序写入，永不覆盖旧日志，保存全量历史操作。

---

2. redo log（重做日志）

• 定义与层次：
  InnoDB 存储引擎层的日志，用于保证事务的持久性（Durability）和崩溃恢复。
• 类型与内容：
  • 物理日志：记录“在某个数据页的哪个位置修改了什么值”，是数据页修改后的最终状态。
  • 通过循环写入固定大小的文件（如 ib_logfile0、ib_logfile1），写满后覆盖旧日志。
• 核心作用：
  • 数据库崩溃时，通过 redo log 重做已提交但未写入磁盘的事务，确保数据不丢失。

---

3. undo log（回滚日志）

• 定义与层次：
  InnoDB 存储引擎层的日志，用于实现事务的原子性（Atomicity）和 MVCC（多版本并发控制）。
• 类型与内容：
  • 记录事务执行前的旧数据版本（如“某行数据修改前的值”），是逻辑日志。
  • 每个事务的 undo log 在事务提交后保留一段时间，支持回滚和一致性读。
• 核心作用：
  • 事务回滚：撤销未提交的事务修改。
  • MVCC：为其他事务提供历史数据快照，避免读写冲突。

---

三者协作机制

1. 事务提交流程：

   • 两阶段提交：
     • 1. prepare 阶段：InnoDB 将事务写入 redo log（状态为“prepare”）。
     • 2. commit 阶段：MySQL Server 层将事务写入 binlog，随后 InnoDB 将 redo log 状态改为“commit”。
   • 若崩溃发生在 prepare 阶段，事务回滚；若发生在 commit 阶段，根据 binlog 和 redo log 一致性决定提交或回滚。

2. 数据恢复与一致性：

   • redo log 恢复已提交的事务，undo log 回滚未提交的事务。
   • binlog 提供全局操作记录，支持主从同步和时间点恢复。

---

关键区别总结

特性	binlog	redo log	undo log
层次	MySQL Server 层	InnoDB 层	InnoDB 层
日志类型	逻辑日志（SQL 语句）	物理日志（数据页修改）	逻辑日志（旧数据版本）
写入方式	追加写，不覆盖	循环写，覆盖旧日志	追加写，事务结束后保留
核心作用	主从复制、增量恢复	崩溃恢复、持久性	事务回滚、MVCC
依赖关系	所有存储引擎通用	仅 InnoDB 支持	仅 InnoDB 支持

---