MySQL 日志架构深度解析：原子性与数据一致性的基石

Corey2025/12/30大约 5 分钟面试题面试题

来源：MySQL 日志架构深度解析：原子性与数据一致性的基石

在数据库系统的设计权衡中，性能与可靠性往往是一对矛盾体。为了解决内存读写速度与磁盘持久化之间的巨大鸿沟，同时保证事务的 ACID 特性，MySQL 构建了一套精密的日志系统。

本文将以可视化的方式，逐层拆解支撑 MySQL 核心运行机制的三大日志体系。

1. 核心架构概览

上图展示了 MySQL 的三大核心日志，它们并非简单的备份文件，而是深度参与到数据处理流程中的关键组件。

设计初衷：数据库为了性能，通常会在内存（Buffer Pool）中修改数据。如果每次修改都直接同步到磁盘数据文件（.ibd），随机 I/O 会导致性能急剧下降。
协作机制：为了解决上述问题，MySQL 引入了WAL（Write-Ahead Logging，预写日志）机制。
Redo Log 保证了“内存数据不丢失”。
Undo Log 保证了“事务执行不彻底时可回退”。
Binlog 则负责将数据变更“广播”给下游系统（如从库或大数据平台）。

MySQL 的“Server 层 + 插件式存储引擎”架构决定了日志的异构性：

特性：它是逻辑日志，记录的是 SQL 语句的原始逻辑（Statement 格式）或行数据的变更前后值（Row 格式）。
独立性：Binlog 不依赖于具体的存储引擎。无论你使用 InnoDB 还是 MyISAM，Binlog 都能记录数据变更。这使得它成为数据恢复（Point-in-Time Recovery）和主从复制的标准载体。

Redo Log：它是物理日志，记录的是“在某个数据页（Page）上做了什么修改”。与 Binlog 的追加写不同，Redo Log 采用循环写（Circular Write）模式，空间固定，用完即覆盖。这意味着它只关注“崩溃恢复”这一短期目标，而不负责长期归档。
关键差异：当数据库发生宕机重启时，Server 层无法通过 Binlog 恢复内存中未刷盘的脏页，必须依赖 InnoDB 特有的 Redo Log 进行重放。

Undo Log 的作用远不止于“回滚”。如图所示，当执行 UPDATE 时，它记录了数据的旧值（OLD_VALUE）。这一机制支撑了两个核心特性：

原子性（Atomicity）：事务执行过程中若发生异常或显式执行 ROLLBACK，引擎会利用 Undo Log 中的反向操作（如将 insert 回滚为 delete），将数据恢复至事务开始前的状态，确保操作的不可分割性。
MVCC（多版本并发控制）：这是 Undo Log 经常被忽视的重要功能。在高并发读取场景下（如 Read Committed 或 Repeatable Read 隔离级别），如果一行数据正在被修改，查询请求不会被阻塞，而是顺着 Undo Log 链（版本链）读取该行数据之前的快照版本。