首页 >> 基础教程

binlog 和 redo log 有什么区别？

binlog（二进制日志）和 redo log（重做日志）是 MySQL 中两个核心但职责完全不同的日志，它们在保障数据一致性、持久性和实现高可用方面扮演着关键但互补的角色。理解它们的区别对于深入掌握 MySQL 事务机制、复制原理和恢复过程至关重要。

以下是它们的主要区别，从多个维度进行对比：

特性	binlog (Binary Log)	redo log (Redo Log)
归属层级	MySQL Server 层 (所有存储引擎都可以使用)	InnoDB 存储引擎层 (InnoDB 特有)
核心目的	数据复制 (Replication) 和时间点恢复 (PITR)	保证事务的持久性 (Durability)
记录内容	逻辑日志： * `STATEMENT`: 记录原始 SQL 语句 * `ROW` (推荐): 记录行数据的变化 (`event`) * `MIXED`: 混合模式	物理日志：记录对物理数据页 (Page) 所做的物理修改 (如：在某个页的某个偏移量处修改了哪些字节)。描述“在哪个页的哪个位置做了什么修改”。
日志作用域	记录所有对数据库进行修改的语句 (DML, DDL)，无论哪个存储引擎执行	只记录 InnoDB 引擎自身对数据页的修改操作
写入时机	事务提交 (COMMIT) 时： 1. 先将 binlog 写入文件系统缓存 (`fsync` 由 `sync_binlog` 控制) 2. 再提交事务到存储引擎	事务进行中： 1. 修改先在内存中进行 (Buffer Pool) 2. 修改产生的 redo 记录先写入 redo log buffer 3. 事务提交时：根据 `innodb_flush_log_at_trx_commit` 设置，将 redo log buffer 中的相关记录刷新到磁盘上的 redo log 文件。早于或同时于 binlog 的持久化。
持久化保证	由 `sync_binlog` 参数控制： * `0`: OS 决定刷盘 * `1` (安全): 每次 commit 都刷盘 * `N`: 每 N 次 commit 刷盘	由 `innodb_flush_log_at_trx_commit` 参数控制： * `0`: 每秒刷盘 (可能丢约1s数据) * `1` (安全): 每次 commit 都刷盘 * `2`: 每次 commit 写文件缓存，每秒刷盘 (OS 崩溃丢约1s数据)
日志文件管理	追加写入 + 滚动归档： * 按 `max_binlog_size` 滚动生成新文件 (`mysql-bin.000001`, `mysql-bin.000002`, ...) * 通过 `expire_logs_days` / `binlog_expire_logs_seconds` 自动清理旧文件 * `mysql-bin.index` 文件记录当前有效的 binlog 文件列表	循环写入 (Circular Buffer)： * 固定大小文件组 (默认 `ib_logfile0`, `ib_logfile1`) * 写满第一个文件后，覆盖写第二个文件，再覆盖写回第一个文件，循环往复 * `innodb_log_file_size` 和 `innodb_log_files_in_group` 控制总大小
崩溃恢复角色	时间点恢复 (PITR)：结合全量备份 + binlog，可以将数据库恢复到备份后的任意时间点。	崩溃恢复 (Crash Recovery)：数据库重启时，InnoDB 检查数据页的 LSN 和 redo log 的 LSN。 * 重做 (Redo)：将 redo log 中记录的、已提交事务但尚未写入数据文件 (`ibd`) 的修改重新应用到数据页 (前滚)。 * 回滚 (Undo)：利用 `undo log` 回滚未提交事务的修改。保证已提交事务的数据不丢失，未提交事务的数据被撤销。
复制角色	核心：Master 将 binlog 发送给 Slave。Slave 的 I/O 线程接收并写入本地的 Relay Log，SQL 线程读取 Relay Log 并重放其中的事件，实现数据同步。	无关：Redo log 仅在单机 InnoDB 内部用于崩溃恢复，不直接参与主从复制。
查看内容	使用 `mysqlbinlog` 工具解析查看 (`mysqlbinlog -v --base64-output=DECODE-ROWS binlog.000001`)	无法直接查看：内容是物理的、面向页的二进制数据，没有官方工具直接解析成可读格式。信息可通过 `SHOW ENGINE INNODB STATUS` 部分或 Performance Schema 间接监控。

为什么需要两个日志？

历史与架构分层： binlog 出现较早，作为 Server 层日志，目的是支持复制和恢复，与存储引擎解耦。redo log 是 InnoDB 为了实现其事务 ACID 特性（尤其是持久性）而引入的物理日志，更贴近底层存储。
职责分离：

binlog 负责逻辑层面的数据变更记录，用于跨实例、跨引擎的数据同步和指定时间点的逻辑恢复。
redo log 负责物理层面的页修改记录，用于保证单个实例内 InnoDB 数据的持久性和崩溃后快速恢复物理数据页的一致性。

性能优化： redo log 的顺序 I/O 写入和循环缓冲区设计，相比直接写随机的数据文件，极大地提升了事务提交的性能（Write-Ahead Logging, WAL 机制）。binlog 的追加写入和归档机制更适合复制和恢复的需求。

结论： binlog 和 redo log 是 MySQL 高可用、数据一致性的基石。binlog 是 Server 层的逻辑日志，主攻复制和基于时间点的逻辑恢复；redo log 是 InnoDB 引擎的物理日志，主攻事务持久性和崩溃恢复。它们通过精妙的两阶段提交 (2PC) 机制协同工作，共同确保了在 MySQL 服务器崩溃的情况下，既能保证已提交事务的数据不丢失（持久性），又能保证主从数据或备份恢复后数据在逻辑上的一致。理解它们的区别和协作原理是深入掌握 MySQL 内核的关键。