关于MySQL的bin log、redo log、undo log

原创已于 2025-10-18 09:04:18 修改 · 704 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#笔记 #mysql #数据库

于 2025-10-18 08:54:33 首次发布

MySQL 专栏收录该内容

1 篇文章

订阅专栏

在 MySQL 中，binlog、redo log、undo log 是三类核心日志，分别服务于不同的功能场景——其中 binlog 属于 MySQL Server 层（所有存储引擎通用），redo/undo log 属于 InnoDB 存储引擎层（专用于 InnoDB 的事务与一致性保障）。三者共同支撑了 MySQL 的数据可靠性、持久性、崩溃恢复及主从复制能力。

一、binlog（二进制日志，Binary Log）

1. 定义

binlog 是 MySQL Server 层记录所有数据变更操作的逻辑日志（记录 SQL 语句或其对应的行变化），以文本或二进制格式存储。

2. 核心作用

binlog 的核心价值是数据归档与主从复制，具体包括：

数据恢复：当数据库发生严重故障（如磁盘损坏）时，可通过备份 + binlog 重放，将数据恢复到故障前的任意时间点（Point-in-Time Recovery, PITR）。
主从复制：主库将 binlog 发送给从库，从库解析并执行 binlog 中的操作，实现主从数据同步（MySQL 主从的核心机制）。
审计：记录所有数据变更，用于合规审计或问题排查。

3. 关键特性

逻辑日志：有两种记录格式： STATEMENT：记录 SQL 语句（如 UPDATE users SET name='张三' WHERE id=1）； ROW：记录行的具体变化（如“id=1 的 name 字段从 '李四' 改为 '张三'”）——更安全，避免主从因 SQL 解析差异导致数据不一致（推荐使用）。
追加写入：binlog 文件不会覆盖，而是按顺序追加（如 mysql-bin.000001、mysql-bin.000002），支持长期归档。
刷盘策略：通过 sync_binlog控制（默认 1）： sync_binlog=1：每次事务提交都将 binlog 刷盘（最安全，确保主从一致，但性能略低）； sync_binlog=0：由操作系统决定刷盘时机（性能高，但可能丢失未刷盘的 binlog）。

二、redo log（重做日志，Redo Log）

1. 定义

redo log 是 InnoDB 存储引擎层记录数据页物理修改的物理日志（记录“将某数据页的某偏移量修改为某值”），以循环写入的方式存储在固定大小的文件中（默认 ib_logfile0、ib_logfile1）。

2. 核心作用

redo log 的核心价值是保证事务的持久性（Durability）和崩溃恢复：

持久性：事务提交时，先将修改写入 redo log（并刷盘），即使此时数据页未刷盘（Buffer Pool 中的内存页），重启后也能通过 redo log 重做修改，恢复数据。
崩溃恢复：数据库重启时，InnoDB 会检查 redo log，重做所有已提交但未刷盘的事务修改（redo操作），确保数据不丢失。

3. 关键特性

物理日志：记录的是数据页的物理变化（如“页号 10 的第 500 字节改为 'X'”），而非逻辑操作，因此恢复效率更高。
循环写入：redo log 文件大小固定，写满后会覆盖旧的日志（因此无需保留历史日志，只需保证最近的修改可恢复）。
刷盘策略：通过 innodb_flush_log_at_trx_commit控制（默认 1）： =1：每次事务提交都将 redo log 刷盘（最安全，确保持久性）； =0：每秒刷盘一次（性能高，但可能丢失 1 秒内的修改）； =2：事务提交时写入 OS 缓存，每秒刷盘（OS 崩溃可能丢失数据，但 MySQL 崩溃不会）。

三、undo log（回滚日志，Undo Log）

1. 定义

undo log 是 InnoDB 存储引擎层记录数据修改前旧值的逻辑日志（记录“将某行记录的某字段从 A 改回 B”），存储在特殊的undo表空间中（默认 undo_001、undo_002）。

2. 核心作用

undo log 的核心价值是保证事务的原子性（Atomicity）和支持 MVCC：

原子性：事务回滚时，通过 undo log 恢复被修改的行到旧版本（逆向执行修改），确保“要么全做，要么全不做”。
MVCC（多版本并发控制）：InnoDB 的 MVCC 依赖 undo log 维护数据的版本链——当其他事务需要读取旧版本数据时（如可重复读隔离级别），可通过 undo log 遍历版本链，获取事务启动时的 consistent snapshot（一致性快照）。

3. 关键特性

逻辑日志：记录的是旧值（如“name 字段从 '张三' 改为 '李四'，undo log 保存 '张三'”），用于回滚或构建旧版本。
版本链：undo log 通过 roll_pointer指针将同一行的多个版本串联成链（如 row → undo log 1 → undo log 2 → ...），MVCC 通过遍历此链获取可见版本。
空间回收：当事务提交后，undo log 中该事务生成的旧版本会被标记为可删除，由后台线程（Purge Thread）清理，避免空间无限增长。

四、三者的核心区别与协作

维度	binlog	redo log	undo log
所属层	MySQL Server 层	InnoDB 存储引擎层	InnoDB 存储引擎层
日志类型	逻辑日志（SQL/行变化）	物理日志（数据页修改）	逻辑日志（旧值/版本链）
核心作用	数据恢复、主从复制	持久性、崩溃恢复	原子性、MVCC
写入时机	事务提交时（Server 层）	事务修改数据页时（Engine 层）	事务修改数据前（Engine 层）
刷盘策略	`sync_binlog`控制	`innodb_flush_log_at_trx_commit`控制	随事务提交自动管理

五、协作流程示例（以 `UPDATE`事务为例）

事务开始：InnoDB 分配事务 ID（trx_id）。
修改数据：将 Buffer Pool 中的数据页修改为新值；将旧值写入 undo log（用于回滚/MVCC）；将物理修改记录写入 redo log buffer（内存）。
事务提交：将 redo log buffer 刷盘（innodb_flush_log_at_trx_commit=1）； Server 层将 binlog 写入文件并刷盘（sync_binlog=1）；标记事务为已提交（undo log 保留旧版本供 MVCC 使用）。
崩溃恢复：重启后，先重做 redo log（恢复未刷盘的数据页）；再通过 binlog 重放未完成的主从同步（若有）。
事务回滚：通过 undo log 恢复数据到旧版本；清理 undo log 中的旧版本（Purge Thread 后续处理）。