MySQL中binlog/redolog/undolog区别是什么
2020-12-30 04:03:26
MySQL中的binlog、redolog、undolog在功能、特性及应用场景上存在显著区别，具体如下：
binlog（二进制日志）
binlog是MySQL Server层的逻辑日志，记录所有修改数据的SQL语句（不包含查询操作），以二进制形式存储。其核心作用是支持主从复制和数据恢复：通过主库将binlog发送至从库，实现数据同步；利用mysqlbinlog工具可基于时间点或位置恢复数据。binlog的写入方式为追加，通过sync_binlog参数控制刷盘时机（0由系统决定，1每事务提交强制刷盘，N为每N个事务刷盘），默认值1在MySQL 5.7.7后为安全首选。日志格式分为STATEMENT（记录SQL语句）、ROW（记录行变更）、MIXED（混合模式），5.7.7后默认采用ROW格式以提升数据一致性。
redolog（重做日志）
redolog是InnoDB引擎的物理日志，用于保证事务的持久性。其通过记录数据页的物理变更（如“将第X页的第Y字节修改为Z”）而非完整数据页，解决直接刷盘性能低下的问题。redolog采用循环写入机制，固定大小的文件分为多个部分，通过write pos（当前写入位置）和checkpoint（已刷盘位置）标记可用空间。当write pos追上checkpoint时，会推动checkpoint前移以腾出空间。redolog的写入分为两阶段：先写入内存中的redo log buffer，再通过innodb_flush_log_at_trx_commit参数控制刷盘时机（1为每次提交均刷盘，0或2为延迟刷盘）。其与binlog的关键区别在于：redolog是物理日志且循环覆盖，仅用于崩溃恢复；binlog是逻辑日志且持续追加，用于归档和复制。
undolog（回滚日志）
undolog是InnoDB引擎的逻辑日志，记录事务修改前的数据状态，用于实现事务的原子性和MVCC（多版本并发控制）。例如，INSERT操作对应DELETE的undolog，UPDATE操作对应反向UPDATE的undolog。当事务回滚时，通过执行undolog中的反向操作恢复数据；在MVCC中，undolog提供旧版本数据供读操作访问，避免阻塞。undolog在事务提交后不会立即删除，而是由后台purge线程在确定无其他事务需要访问旧版本后清理。
三者核心区别
- 层级与作用：binlog属于Server层，支持复制与恢复；redolog和undolog属于InnoDB层，分别保障持久性与原子性。
- 日志类型：binlog为逻辑日志（记录SQL或行变更），redolog为物理日志（记录数据页变更），undolog为逻辑日志（记录反向操作）。
- 生命周期：binlog持续追加且永久保存；redolog循环覆盖；undolog在事务提交后逐步清理。
- 应用场景：binlog用于跨库同步与全量恢复；redolog用于崩溃恢复；undolog用于事务回滚与并发读。
三者协同工作：事务提交时，先写redolog保证持久性，再写binlog支持复制，同时生成undolog支持回滚；崩溃恢复时，通过redolog修复未刷盘的数据页，通过binlog补全未记录的操作。
热门标签
