当前位置：首页 > news >正文

MySQL的三大核心日志详解（redo log，bin log，undo log）

news 2026/3/26 18:55:24

MySQL的三大核心日志——redo log、binlog和undo log——是保障数据一致性、实现崩溃恢复以及支持高可用架构的基石。它们各有分工，又相互协作。

我先用一个表格帮你快速建立起对它们核心区别的直观认识，然后再详细拆解它们各自的作用、使用方法以及如何协同工作。

📝 三大核心日志对比一览

特性	redo log (重做日志)	binlog (二进制日志)	undo log (回滚日志)
日志类型	物理日志，记录“数据页做了什么修改”。	逻辑日志，记录原始SQL语句或行变更逻辑。	逻辑日志，记录数据修改前的状态。
所属层级	InnoDB存储引擎层特有的。	MySQL Server层，所有引擎都可使用。	InnoDB存储引擎层特有的。
主要作用	保证事务的持久性(Durability)，实现崩溃恢复(crash-safe)。	用于数据恢复(PIT恢复)和主从复制。	保证事务的原子性(Atomicity)，支持事务回滚和MVCC。
写入方式	循环写，空间固定，会覆盖旧记录。	追加写，写满一个文件就创建新文件，保存全量历史。	同样追加写，但会记录旧数据形成版本链，用于回滚和MVCC。

接下来，我们通过具体的示例来看看它们是如何工作的。

🔍 日志详解与使用示例

1. undo log (回滚日志)

作用：它是保障事务原子性的关键。它记录了事务开始前数据的“旧值”。如果事务执行失败或执行了ROLLBACK，MySQL可以利用undo log将数据恢复到这个事务开始前的状态。
进阶用途：它也是实现MVCC（多版本并发控制）的核心。当多个事务并发读取同一条记录时，undo log中记录的多个版本可以确保每个事务读到它应该看到的那个数据快照。

使用示例（事务回滚）：

假设有一张表account，id=1的余额balance=100。我们开始一个事务，将余额更新为200，但中途反悔了，决定回滚。

-- 1. 开启事务STARTTRANSACTION;-- 2. 执行更新操作。此时，MySQL会先将旧值(100)记录到undo log中，然后再更新内存中的数据。UPDATEaccountSETbalance=200WHEREid=1;-- 3. 检查数据后发现更新错了，决定回滚。-- 此时，MySQL会读取之前记录的undo log，将数据恢复为旧值100。ROLLBACK;-- 4. 再次查询，数据回到了100。SELECT*FROMaccountWHEREid=1;-- 结果 balance = 100

在这个例子中，ROLLBACK命令能够生效，全靠undo log里记录的那份“旧值”数据。

2. redo log (重做日志)

作用：它保证了事务的持久性。MySQL采用了WAL (Write-Ahead Logging)技术，更新数据时，不直接写磁盘数据文件，而是先顺序写入redo log。这样即使数据库突然崩溃，已提交事务的数据尚未写入数据文件，重启后也可以通过重放redo log来恢复数据，这就是crash-safe能力。
为何更快：写redo log是顺序I/O，而写数据文件是随机I/O，顺序写的性能远高于随机写。
使用示例（崩溃恢复）：
- 假设你在执行一个更新操作，更新id=1的记录。InnoDB会把这个更新记录到redo log中，然后将内存中的数据页标记为“脏”。此时，即使数据文件还没更新，事务也算提交成功了。
- 如果数据库在此时突然宕机，重启后，MySQL会自动扫描redo log，将这个已提交但还未写入数据文件的更新操作“重做”一遍，确保数据不丢。

3. binlog (二进制日志)

作用：作为Server层的日志，它记录了所有修改数据库内容的操作（DDL和DML，不包括SELECT）。它的核心功能是数据恢复和主从复制。
使用示例（数据恢复）：
- binlog以事件的形式记录了所有变更。你可以使用mysqlbinlog工具来解析它，并恢复到某个时间点或某个位置的数据。
- 假设你在中午12点误执行了一条DELETE FROM important_table，需要恢复到误操作前的状态。
- 恢复思路：先利用之前的全量备份恢复数据库，然后使用mysqlbinlog工具，提取从备份时间点到中午12点之前的所有binlog（排除了那条错误的DELETE语句），并将其应用到数据库。
```
# 解析binlog，将指定时间范围内的操作导出为SQL文件mysqlbinlog --start-datetime="2024-01-01 10:00:00"--stop-datetime="2024-01-01 11:59:59"/var/lib/mysql/binlog.000001>recovery.sql# 然后执行这个SQL文件进行恢复mysql-uroot-p<recovery.sql
```
  这个命令就是从binlog.000001文件中，提取出指定时间段内的操作，并生成一个SQL文件。

🤝 它们是如何协同工作的？以更新语句为例

为了确保数据的一致性，这三个日志在一条更新语句的执行过程中密切配合。这里有一个经典的“两阶段提交”流程：

假设我们要执行UPDATE user SET age=19 WHERE id=1;

准备阶段：
- 执行器找到id=1这行数据（可能从内存或磁盘）。
- 在更新这行数据前，先记录undo log，将age=18这个旧值保存下来，以便回滚。
- 执行器更新内存中的数据页，将age改为19。
- InnoDB引擎将这个更新操作写入redo log，并将其状态标记为prepare（准备）阶段。这时redo log已经持久化到磁盘。
写入binlog：
- 执行器生成这条操作的binlog，并将其写入磁盘（持久化）。
提交阶段：
- 执行器通知InnoDB引擎，事务可以提交了。
- InnoDB将刚才那条处于prepare状态的redo log，更新状态为commit（提交）。至此，整个事务才算真正完成。

为什么要这么麻烦？两阶段提交的作用
这个机制是为了保证redo log和binlog这两个日志的逻辑一致性。

情况A：如果在写入binlog之前，系统崩溃了。重启后，由于redo log处于prepare状态，但binlog还没写，说明这个事务是未完成的，就会通过undo log进行回滚。
情况B：如果在binlog写入成功后、redo log变为commit前崩溃了。重启后，虽然redo log是prepare状态，但检查到对应的binlog已经完整写入，MySQL就会认为这个事务是完整的，提交这个事务。

通过这种方式，就确保了无论是在主从复制还是崩溃恢复中，数据都是一致的。

希望这份详细的梳理能帮你更好地理解MySQL的三大日志。如果后续想深入了解MVCC的原理，或者binlog不同格式的区别，随时可以再来问我。

查看全文

http://www.jsqmd.com/news/531559/