MySQL Redo与Undo日志详细解析

陆遥

发布时间：2026-10-15 | 4人浏览过

原创

本文详细解析MySQL中核心的Redo日志与Undo日志机制。Redo日志用于保障数据不丢失并提升写入效率，通过Minimally-Transactional-Record（MTR）机制实现高效落盘；Undo日志记录数据变化以支持事务回滚和MVCC多版本并发控制。文章同时介绍了Checkpoint在日志清理与数据库快速恢复中的作用。

Redo日志的核心原理

Redo日志是InnoDB存储引擎特有的物理日志，主要记录的是“页”级别的物理修改。它的核心作用在于两点：一是通过在内存中预写日志（Write-Ahead Logging），减少随机IO操作，从而提升数据库的写入效率；二是当系统发生崩溃或宕机时，利用Redo日志重放已提交的事务，保证已提交的数据不丢失，实现数据的持久性（Durability）。

Redo日志的三层结构

为了实现高效的写入、读取与清理，Redo日志从上到下分为三层：

逻辑REDO层：这是最上层的抽象，由多个不同类型的Redo记录组成。每个记录拥有全局唯一的递增偏移量序列号（LSN）。InnoDB会在全局log_sys中维护当前最大的LSN值，每次写入数据时，该值会增加本次写入内容的长度。
物理REDO层：由于磁盘是块设备，InnoDB内部也使用Block概念进行数据读写。一个Block的大小（即OS_FILE_LOG_BLOCK_SIZE）通常等于磁盘扇区大小512B。这意味着每次IO的最小读写单位都是一个Block。
文件层：最终生成的Redo信息会被顺序写入到磁盘上的Redo日志文件中（通常是ib_logfile0等文件），这些文件采用循环写入的模式。

MTR写入流程与CheckPoint机制

Redo日志的写入流程（MTR）

MTR（Mini Transaction Record）是InnoDB保证最小事务记录原子性的关键机制。用户线程的操作遵循以下标准流程：

进入Log Buffer：用户线程对数据页做的修改，首先会生成对应的Redo日志并写入共享内存中的log buffer区域。
转换为逻辑日志：log buffer中的碎片化日志会被整理成连续的Redo逻辑日志流。
持久化落盘：根据刷盘策略（如innodb_flush_log_at_trx_commit配置），日志被顺序写入磁盘的Redo文件。
完成通知：一旦确认写入磁盘成功，数据库内核才会通知用户线程操作已完成。

Checkpoint机制与数据库恢复

Checkpoint是Redo日志中的一个重要标记位，它记录了后台脏页刷入磁盘的最高LSN。其作用包括：方便清理无用的Redo日志片段，以及大幅减小数据库重启时的回放工作量。

当数据库意外重启时，恢复流程大致如下：

读取Checkpoint：系统从最新的Checkpoint位置开始读取剩余的Redo日志。
构建Hash表：解析日志并根据空间ID（space_no）与页面ID（page_id）构建临时索引结构。
应用Redo日志：重放日志至数据页。此过程具有幂等性，确保多次回放结果一致。
处理Binlog：解析二进制日志（binlog）构建待检查的事务ID列表（xid list）。
一致性决策：扫描回滚段，构建需要回滚的事务列表。如果在xid列表中未找到某事务，则说明该事务可能在双写缓冲后、崩溃前提交了，需根据具体情况判断是否执行回滚或提交。

Undo日志与MVCC并发控制

Undo日志介绍

与Redo不同，Undo log是逻辑日志，记录的是数据行的反向操作（例如插入的反向是删除，更新的前后镜像对比）。它的主要职责包括：

事务原子性：允许事务在执行过程中随时进行回滚（Rollback）。
多版本并发控制（MVCC）：为一致性读提供历史快照，解决读写冲突。

MVCC的运作机制

MVCC的核心意义在于实现读写互不阻塞，降低死锁概率，并提供非锁定的一致性读。其在底层依赖UndoLog的实现细节如下：

事务ID追踪：每个事务在开启时都会获得一个单调递增的事务ID（Transaction ID）。
行版本标识：InnoDB的每一行数据除了业务字段外，还隐藏包含了三个列：
- DB_ROW_ID：隐藏的主键。
- DB_TRX_ID：最近修改该行数据的事务ID。
- DB_ROLL_PTR：回滚指针，指向该版本之前的旧版本数据。
版本链管理：通过DB_ROLL_PTR，可以将同一数据行的所有历史快照串联成一个链表。查询时，MVCC算法会根据当前事务的可见性规则，沿着这条链表找到对该事务可见的历史版本。