MySQL事务日志机制：redo log与undo log详解

1. 深入理解MySQL事务日志机制

作为一名长期与MySQL打交道的数据库工程师，我经常需要向团队新人解释redo log和undo log的工作原理。这两种日志是InnoDB存储引擎实现事务ACID特性的核心技术，理解它们对优化数据库性能和保证数据安全至关重要。

事务的四大特性中，持久性(Durability)依赖redo log实现，原子性(Atomicity)则由undo log保障。隔离性(Isolation)通过锁机制和MVCC实现，而一致性(Consistency)实际上是前三个特性共同作用的结果。今天我们就重点剖析这两种日志的工作机制和实际应用场景。

2. redo log：保障持久性的关键设计

2.1 redo log的核心作用与物理结构

redo log（重做日志）是InnoDB存储引擎层的物理日志，记录的是数据页的物理修改。与常见的逻辑日志不同，它不记录SQL语句，而是记录"在某个数据页上做了什么修改"，格式类似于："页号xx，偏移量yyy写入了'zzz'数据"。

这种设计带来几个关键优势：

1. 日志体积小：物理日志通常比逻辑日志更紧凑
2. 恢复速度快：重做时直接应用物理修改，无需重新解析SQL
3. 并发性能好：不同事务对同一页的修改可以合并写入

重要提示：redo log记录的是数据变更后的状态，而undo log记录的是变更前的状态，两者配合才能实现完整的事务特性。

2.2 redo log的完整工作流程

以一个UPDATE语句为例，redo log的生成过程如下：

1. 数据加载阶段：

   • 从磁盘读取目标数据页到Buffer Pool
   • 在内存中修改数据页内容

2. 日志生成阶段：

   • 生成描述这次修改的redo记录
   • 将redo记录写入redo log buffer

3. 事务提交阶段：

   • 将redo log buffer内容刷新到redo log文件
   • 返回成功响应给客户端

4. 异步刷盘阶段：

   • 后台线程定期将脏页(被修改的数据页)刷回磁盘
   • 刷盘完成后可复用对应的redo log空间

2.3 为什么需要redo log：三大核心优势

2.3.1 解决"修改