MySQL 的 Redo Log 和 Binlog 是两种完全不同、但又紧密协同的日志机制。理解这两种日志对理解 MySQL 的事务机制有重要帮助。今天来聊一聊这两种日志。1.概念回顾1.1 两阶段提交我们知道分布式事务一般都是使用两阶段提交达到最终一致。比如下图一个购买商品的案例用户下订单后订单服务保存订单账户服务扣减金额库存服务扣减库存。这三个服务通过两阶段提交先 prepare,然后 commit 最终实现事务一致性。1.2 事务提交我们再来看一下 MySQL 的逻辑架构看下图在 MySQL 逻辑架构中执行器负责执行具体的 SQL跟存储引擎进行交互。执行器就是两阶段提交的“事务协调者”事务执行过程如下图假如我们要执行一条 SQL:update t set a10 where id5;这个 SQL 的执行过程如下执行器先从存储引擎拿到 id5 这一行数据然后把这一行数据的字段 a 改成 10再把这行修改后的数据写入存储引擎。prepare 阶段存储引擎将这行新数据写入内存同时将这行数据的更新操作记录到 Redo Log 但不提交事务然后给执行器返回成功。此时 Redo Log 处于 prepare 状态。执行器为这行数据的更新操作生成 Binlog 并写入磁盘当然是否刷盘要根据 sync_binlog 配置来决定。commit 阶段执行器通知存储引擎提交事务存储引擎把刚刚写入的 Redo Log 改成提交 commit 状态完成事务提交。2.Redo Log2.1 介绍从前面介绍可以看到Redo Log 是存储引擎层控制的日志事实上Redo Log 是 InnoDB 存储引擎特有的日志它是一个物理日志 记录了在某个数据页上做了哪些修改主要用于崩溃恢复。Redo Log 的刷盘机制通过下面参数来控制innodb_flush_log_at_trx_commit0事务提交时Redo Log 不会被立刻被写入磁盘而是存在缓存中Redo Log BufferInnoDB 后台日志线程每秒将日志从缓冲区写入文件系统缓存Page Cache然后调用 fsync 落盘。优点是减少了 I/O 操作提升了性能缺点是如果 MySQL 服务挂了或者操作系统宕机可能丢失 1s 的数据。1默认值。事务提交时Redo Log 立即写入 Page Cache并调用 fsync 保存磁盘优点是系统宕机时丢失数据风险小缺点是磁盘 I/O 操作频繁影响性能。2事务提交时Redo Log 被直接写入到 Page Cache然后依赖操作系统的刷盘机制将 Page Cache 中的日志写入磁盘优点是性能好如果 MySQL 服务挂了并不会导致数据丢失只有操作系统宕机Page Cache 未刷盘的数据才会丢失。2.2 写日志在写数据时Redo Log 是循环写空间大小固定写满后会覆盖掉前面的日志。Redo Log 采用固定大小的文件组比如下图文件组配置了 4 个文件每个文件大小相同写满一个后接着写下一个全部写满后就清除一部分前面的日志继续写入。write pos 控制当前写入的位置check point 控制可以写入的最后位置如果两个点重合了那就需要清除部分日志让 check point 后移。2.3 Redo Log 使用场景崩溃恢复这是 Redo Log 最根本的用途。它确保了数据库宕机后已提交事务的数据不会丢失。Redo Log 基于 WAL (Write-Ahead Logging) 原则即先写日志再写磁盘。事务提交时先将修改内容的记录到 Redo LogMySQL 宕机重启后利用 Redo Log 做崩溃恢复。恢复过程如下。首先InnoDB 会检查数据页的 LSN (日志序列号)并与 Redo Log 中的 LSN 对比。Redo Log 上 LSN 比数据页大的就是需要重做的数据。接着InnoDB 会扫描 Redo Log 中要恢复的日志如果日志状态是 COMMIT则直接重做。如果日志状态是 PREPARE则还要去检查对应的 Binlog如果该事务的 Binlog 存在且完整说明事务已经提交成功应该重做。如果该事务的 Binlog 不存在或不完整说明事务应该回滚Redo Log 日志不进行重做。通过这个机制确保了 Redo Log 和 Binlog 的逻辑一致性只要 Binlog 写成功了数据就一定能够被恢复如果 Binlog 没写成功说明事务应该被回滚数据无需恢复。优化性能通过将数据文件随机写磁盘转换为 Redo Log 顺序写磁盘大大提升了事务执行效率和数据库整体吞吐量。3.Binlog3.1介绍Binlog 是 MySQL Server 层的日志所有引擎都可以使用。它是一个逻辑日志记录的是数据逻辑的变化比如插入一条数据用于主从复制和故障恢复。跟 Redo Log 写日志方式不同的是 Binlog 是追加写写满一个文件后切换到下一个文件写。3.2 刷盘时机MySQL 中 sync_binlog 参数定义了将 Binlog 内容从内存缓冲区同步到磁盘的频率。0MySQL 不会主动将 Binlog 内容同步到磁盘完全依赖文件系统刷盘机制来落盘。这种方式磁盘 I/O 操作较少性能最好但存在数据丢失的风险。1每次事务提交时都会将 Binlog 内容同步到磁盘。这种方式丢失数据的风险较小但因为磁盘 I/O 操作多容易影响数据库性能。NN1每 N 个事务提交后才会将 Binlog 内容同步到磁盘。这种方式是前两种方式的折中既考虑了一定的性能也兼顾了数据的安全性。3.3 Binlog 使用场景主从复制这是 Binlog 最重要的用途。在主从架构中Master 节点将自己的 Binlog 发送给 Slave 节点Slave 通过重放 Binlog 中的 SQL 语句实现数据同步。点播恢复因为 Binlog 完整记录了对数据库的所有更改操作它可以通过重放来恢复某一个时间段的全部数据。在实际工作中有时我们需要恢复数据库到某一个历史时间点的状态这时我们可以找出这个时间点之前最近的一个全量备份用这个全量备份恢复到一个空数据库然后找出全量备份时间点到目标时间点之间所有 Binlog 文件并进行回放。这样就实现了精确的时间点恢复。这对于修复误操作如误删表、误更新非常有用。总结Redo Log 保存在 InnoDB 中用于保证宕机后数据不丢是 MySQL 支持数据库事务的基础。Binlog 保存在 MySQL server 层用于主从同步或点播恢复。两者分工明确但又紧密协作共同保障了 MySQL 数据安全和高可用性。为了让两个日志区别更清晰总结下表特性Redo LogBinlog归属InnoDB 存储引擎Server 层日志类型物理日志记录对数据页修改逻辑日志记录修改 SQL 或行变化用途崩溃恢复主从同步、点播恢复写磁盘循环写追加写