mysql中事务日志（redo log）如何工作

redo log是InnoDB实现持久性的核心，通过WAL先写日志再改数据，确保提交事务不丢失；其顺序写入和循环利用提升IO效率，崩溃时重做日志恢复未刷盘的脏页，保障数据一致性。

MySQL 中的事务日志，即 redo log（重做日志），是 InnoDB 存储引擎实现持久性和崩溃恢复的核心机制之一。它确保了即使在数据库意外宕机的情况下，已提交的事务也不会丢失数据。

redo log 的基本作用

redo log 记录的是“物理级别”的修改，也就是对数据页的具体更改操作，例如“在某数据页的某个偏移量处写入了某些字节”。它的主要目标是：保证事务的持久性（Durability），即一旦事务提交，其修改就能永久保存，即使系统崩溃也能恢复。

InnoDB 使用一种叫作 Write-Ahead Logging（WAL，预写日志） 的策略：所有对数据的修改必须先写入 redo log，然后再更新内存中的数据页（脏页），实际的数据文件（磁盘上的 .ibd 文件）可以稍后由后台线程异步刷盘。

redo log 的工作流程

当一个事务执行并提交时，redo log 按照以下步骤工作：

• 事务开始修改数据：InnoDB 先将数据页加载到内存（Buffer Pool），然后在内存中修改它。
• 生成 redo 日志条目：同时，InnoDB 将该修改操作记录到 redo log buffer（内存中的日志缓冲区）。
• 事务提交时写入磁盘：在事务提交时，redo log buffer 中对应的日志会通过 fsync 操作被强制写入到磁盘上的 redo log 文件（通常为 ib_logfile0 和 ib_logfile1）。
• 后续刷脏页：被修改的数据页（脏页）则由后台线程在合适时机刷回到磁盘数据文件中，这个过程可以延迟。

这种机制的好处是：磁盘 I/O 更高效。redo log 是顺序追加写入，比随机写数据文件快得多。而数据页的刷新可以批量、异步进行，不阻塞事务提交。

redo log 的结构与循环写入

redo log 文件是一组固定大小的文件，构成一个逻辑上的环形缓冲区。例如，如果有两个 1GB 的日志文件，总容量为 2GB，写满后会从头开始覆盖。

如知AI笔记

如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

27

查看详情

但不能无限制覆盖，因为某些老的日志对应的数据页可能还没刷回磁盘。InnoDB 使用一个叫 checkpoint 的机制来跟踪哪些 redo log 已经“不再需要”用于恢复。

简单来说：只有当对应的脏页被刷入磁盘后，其对应的 redo log 才能被覆盖。这样就保证了崩溃恢复时有足够的日志可用。

崩溃恢复时 redo log 的作用

如果 MySQL 崩溃重启，InnoDB 会自动进行恢复：

• 读取 redo log 中未确认完成刷盘的事务操作。
• 重新应用这些操作（即“重做”），将数据页恢复到崩溃前已提交的状态。
• 确保所有已提交事务的修改都反映在数据文件中。

这个过程对用户完全透明，是 MySQL 实现 ACID 中 D（持久性）的关键支撑。

基本上就这些。redo log 不复杂但容易忽略，理解它有助于掌握 MySQL 的底层可靠性机制。

以上就是mysql中事务日志（redo log）如何工作的详细内容，更多请关注php中文网其它相关文章！