MySQL InnoDB持久化与回滚机制解析：redo log与undo log原理详解

redo log：数据持久性的保障

当我们执行一条更新语句时，例如：

update user set age=11 where user_id=1;

InnoDB的处理流程通常包含以下几个步骤：

• 检查该数据页是否在缓冲池（Buffer Pool）中，若不在则从磁盘读取加载至内存。
• 修改内存中的数据页。
• 写入 redo log，此时日志状态为 prepare。
• 写入 binlog（Server层生成）。
• 提交事务，将 redo log 标记为 commit 状态。

为什么先更新内存而非直接写磁盘？

直接操作磁盘涉及大量随机 I/O，性能极低且维护索引（如B+树）会导致严重的“页分裂”开销。为此，InnoDB采用缓冲池架构，所有变更先在内存完成，再由 Master 线程定期将“脏页”刷入磁盘（即 CheckPoint 机制），以掩盖 CPU 与磁盘间的速度差异。

为什么需要 redo log？

CheckPoint 并非实时触发，若数据库在脏页刷盘前崩溃，内存数据将永久丢失，违背 ACID 中的“持久性”。InnoDB 采用 WAL（Write-Ahead Logging，预写式日志）技术：先写日志，再写磁盘。只要 redo log 成功写入，即使系统宕机，重启后也能根据日志重做操作，从而保证数据不丢。

redo log 的存储与刷盘策略

redo log 首先写入内存缓冲区 redo log buffer，随后由 Master 线程同步到磁盘文件。redo log 默认文件大小为 48M（50331648 字节），通常由两个文件循环组成一个 Log Group。

# 查看 redo log 大小 (默认约 48MB)
show variables like 'innodb_log_file_size';

# 查看 Log Group 内文件数 (默认 2)
show variables like 'innodb_log_files_in_group';

redo log 以 512 Bytes 为一个 Block 存储，包含头信息、主体和尾部。由于机械硬盘扇区通常为 512 字节，这种设计确保了单次写入操作的原子性：若只写入半个扇区可能导致物理损坏，而按扇区对齐写入可保证要么全成功要么全失败。

日志刷盘的频率由 innodb_flush_log_at_trx_commit 参数控制：

• 值 = 1（推荐）：每次事务提交时，Master 线程立即将 buffer 刷入 OS Cache 并强制 fsync 到磁盘。安全性最高，但 I/O 开销最大。
• 值 = 2：提交时仅刷入 OS Cache，不执行 fsync，交由操作系统决定时机。性能较好，但断电可能丢失最后一秒的数据。
• 值 = 0：每秒一次 fsync。性能和安全性均弱于 1。

两阶段提交（2PC）

为保证事务的一致性，redo log 与 binlog 必须保持逻辑一致。采用两阶段提交：

1. Prepare：记录 redo log，状态置为 Prepare，并关联 XID。
2. Commit：写入 binlog。
3. Commit：再次修改 redo log，状态置为 Commit。

这种机制解决了 binlog 已写但 redo 未写（或反之）导致的主从不一致问题。若在主库写入 binlog 后崩溃，主库恢复时会丢弃该事务；而从库在执行日志时，会发现 binlog 有记录但对应的 redo log 处于 Prepare 状态，此时从库会查询主库是否真正提交。若主库已崩溃无法查询，依靠 binlog 的完整性来判定事务有效性。

崩溃恢复（Crash Recovery）

重启时，InnoDB 扫描 redo log：

• 若事务状态为 commit：直接重做操作。
• 若事务状态为 prepare：去查 binlog。若 binlog 中存在该 XID，说明事务已完整提交，执行 Commit；若不存在，说明写入 binlog 时崩溃，执行 Rollback。

undo log：事务原子性的保障

若事务执行过程中出错需要回滚，InnoDB 依赖 undo log 将数据恢复到事务开始前的一致状态。此外，undo log 还用于支持 MVCC（多版本并发控制）。

Undo Log 的产生与记录方式

每行记录的页结构中隐藏了三个重要字段：

• DB_ROW_ID：主键缺失时的自增隐藏主键。
• DB_TRX_ID：最近修改该行的事务 ID。
• DB_ROLL_PTR：指向 undo log 的回滚指针。

不同操作生成的 Undo Log 逻辑不同：

• INSERT 操作：产生 Insert Undo Log。回滚时，直接利用主键删除该行数据。
• UPDATE/DELETE 操作：产生 Update Undo Log。回滚时，需要记录原始数据并将其“还原”回原来的样子。

当更新主键或进行 Delete Mark 标记时，InnoDB 不会物理删除磁盘上的旧数据，而是通过 undo log 链串联旧版本数据。回滚时，沿着 undo no 递增的方向逆向查找，逐条还原数据直到事务起点。

Undo 页的管理与重用

Undo log 存储在回滚段（Rollback Segment）中。InnoDB 默认开启 128 个 Undo 日志槽（innodb_undo_logs），每个槽最多容纳 1024 个 Undo Segment。

# 查看默认回滚段数量
show variables like 'innodb_undo_logs';

# 查看默认的页面大小
show variables like '%innodb_page_size%';

为避免频繁申请新页消耗磁盘空间，Undo Page 支持重用。当事务正常提交后，旧的 Undo Page 进入空闲链表。若其使用率低于 3/4，会被重新分配给后续事务复用；否则才由后台清理线程真正释放磁盘空间。这有效降低了长生命周期事务对存储空间的占用。

以上就是关于 MySQL InnoDB 引擎中 redo log 实现持久化以及 undo log 实现回滚原理的详细内容，更多关于 MySQL 数据库底层原理的资料请关注本站其它相关文章！