MySQL三大日志详解：Undo Log、Redo Log和Binlog的作用与工作机制

发布时间：2025-11-05 13:48:14 来源：创站工坊 作者：域名

前言

MySQL中的日志Undo Log、Redo Log 和Binlog是详解保障数据库事务安全、数据一致性和高可用性的作用核心组件。它们分工明确，工作协同工作，机制但各自有不同的日志设计目标和实现机制。

Undo Log：保障事务原子性与 MVCC 的详解基石

Undo Log主要用于事务回滚以及实现多版本并发控制（MVCC）。在事务执行过程中，作用当进行诸如INSERT、工作UPDATE、机制DELETE等写操作时，日志数据库会将修改前的详解数据副本记录在Undo Log 中。这样一来，作用如果事务执行过程中出现异常或者用户主动执行ROLLBACK操作，工作数据库可以依据Undo Log中的机制记录，将数据恢复到事务开始前的状态，从而保证了事务的原子性，即事务中的所有操作要么全部成功执行，要么全部不执行。

同时，在MVCC场景下，当一个事务对数据进行修改时，其他事务在读取数据时，若读取的亿华云计算行被锁定，就可以从Undo Log中获取该行数据在之前版本的状态，实现非阻塞读，提升数据库的并发性能。

根据操作类型，Undo Log可分为Insert Undo Log和Update Undo Log：

Undo Log存储在InnoDB的Undo Tablespace中，其管理通过Rollback Segment（回滚段）来实现。每个Rollback Segment包含多个Undo Log Slot，用于存储Undo Log记录。

Redo Log：确保事务持久性的关键

Redo Log主要用于确保事务的持久性。当事务提交时，MySQL并不会立刻将所有修改的数据刷新到磁盘，因为磁盘I/O操作相对较慢，这样会严重影响性能。亿华云而是先将修改内容记录到 Redo Log中，之后再异步地将数据写入磁盘。即使在数据库发生崩溃、断电等故障时，只要Redo Log 存在，系统在重启后就可以依据Redo Log中的记录，重新应用已提交事务的修改，保证已提交事务的数据不会丢失，从而实现事务的持久性。

InnoDB采用Write-Ahead Logging（WAL）机制，即先写日志，再写磁盘。每次事务提交时，InnoDB会先将Redo Log写入磁盘，而后再逐步将实际修改的数据写入磁盘。在执行INSERT、UPDATE或DELETE操作时，数据库会首先将修改记录写入Redo Log缓存。当事务提交时，系统会将Redo Log缓存中的内容刷入磁盘上的Redo Log文件。

Redo Log文件通常以循环的方式使用，当一个Redo Log文件写满后，会切换到下一个文件继续写入。InnoDB存储引擎中，Redo Log的写入操作是顺序的，这相较于随机写磁盘，大大提高了写入性能。在系统运行过程中，InnoDB会定期将Redo Log中的修改应用到数据页，并将脏页（即被修改但还未写入磁盘的数据页）刷新到磁盘。

当数据库崩溃后重启，MySQL会进入恢复阶段。首先，进行Redo前滚阶段，通过Redo Log 恢复已提交事务的数据页；然后，扫描未提交事务的Undo日志，并按日志序列号（LSN）逆序执行补偿操作，例如将INSERT操作补偿为DELETE操作，UPDATE操作还原为修改前的状态，从而确保数据库的数据一致性。

Binlog：数据备份、恢复与复制的利器

Binlog（二进制日志）主要有两个重要作用。其一，用于数据库的点时间恢复。通过记录数据库执行的所有写操作，在需要时可以根据Binlog中的记录，将数据库恢复到指定时间点的状态。其二，在主从复制架构中，Binlog起着关键作用。主库将自身执行的写操作记录到Binlog中，从库通过读取主库的Binlog，并在本地重放这些操作，从而实现与主库的数据同步，保证主从库数据的一致性。

Binlog记录的并非所有SQL语句，而是包含了已执行的SQL 语句（增、删、改）的反向信息。例如，DELETE操作在Binlog中对应的是反向插入操作；UPDATE操作对应的是更新前后的版本信息；INSERT操作对应的是DELETE和INSERT操作。通过使用 mysqlbinlog工具解析Binlog，可以清晰地看到这些记录。

当一个事务提交时，该事务中的每一条SQL 语句（一个事务可能对应多条SQL语句）都会以特定格式记录在Binlog中。与Redo Log不同的是，Redo Log在事务开始后就逐步写入磁盘，而Binlog是在事务提交时一次性写入。Binlog的默认保留时间由expire_logs_days 参数设置，超过该时间的非活动日志文件会被自动删除。

在主从复制过程中，主库会将Binlog发送给从库，从库接收后，按照Binlog中的记录顺序，在本地依次执行相应的SQL操作，从而使从库的数据与主库保持一致。这种方式使得MySQL的主从复制架构能够高效地实现数据的同步与备份，为数据的高可用性和灾难恢复提供了有力支持。

关联与协同工作

当一个事务开始执行，Undo Log率先发挥作用，以UPDATE操作为例：

流程图

当MySQL 数据库遭遇崩溃、断电等故障后重启，Redo Log和Undo Log会紧密配合完成数据恢复工作。

而Binlog在故障恢复中，主要用于基于时间点的恢复。如果数据库因误操作等原因需要恢复到某个特定时间点的状态，可以通过解析Binlog，获取从数据库备份时间点到指定时间点之间的所有写操作记录，在恢复的数据库实例上重放这些操作，从而将数据库恢复到指定时间点的状态。

在MySQL主从复制架构中，Binlog是主从库数据同步的核心。主库在执行写操作时，将这些操作记录到Binlog中，从库通过I/O线程连接主库，获取主库的Binlog日志，并将其保存在从库的中继日志（Relay Log）中。

从库的SQL线程读取中继日志中的内容，并在本地依次执行相应的SQL操作，实现与主库的数据同步。在这一过程中，Redo Log和Undo Log同样发挥着重要作用。从库执行中继日志中的 SQL操作时，如同在本地执行事务，Redo Log记录着这些操作对数据的修改，保障从库事务的持久性；Undo Log则用于处理可能的事务回滚，确保从库数据的一致性。

例如，当从库执行一个UPDATE操作时，Redo Log记录该操作的修改，Undo Log记录修改前的数据版本，若事务执行过程中出现异常，可通过Undo Log回滚事务；而Binlog则作为主从库数据同步的桥梁，源源不断地将主库的写操作传递给从库。

总结

理解这三大日志之间的协同关系，有助于数据库管理员更好地进行数据库管理、性能优化和故障排查，也能让开发人员在设计和开发数据库应用时，充分利用数据库特性，构建出更加稳定、可靠、高效的应用系统。

相关文章