MySQL 里这三个 log 关注的点不一样，可以简单理解成：

* binlog：**主从复制 / 增量备份** 用的「归档日志」（逻辑日志）
* redo log：**崩溃恢复 / 持久化** 用的「重做日志」（物理日志，InnoDB 专用）
* undo log：**回滚 / MVCC** 用的「回滚日志」（版本快照，InnoDB 专用）

下面分开说下作用和关系。

---

## 1\. binlog（Binary Log）

**是谁的日志**：MySQL Server 层（所有引擎共有）

**记录内容**：语句/行级别的「数据变更事件」，比如：

* 执行了一条 `INSERT ...`、`UPDATE ...`、`DELETE ...`
* 或者一组事务内的多条 DML

**主要用途**：

1. **主从复制**
   * 主库把事务 commit 后对应的 binlog 发送给从库；
   * 从库按顺序「重放」这些事件，达到与主库数据一致。

2. **增量备份 / point-in-time 恢复**
   * 先做一次全量备份，再用 binlog 回放到指定时间点或指定位置。

**特点**：

* 逻辑日志（记录「做了什么」），跟存储引擎实现解耦；
* 以「事务为单位」写：事务提交时一次性写入并 `fsync`（可配置）。

---

## 2\. redo log（重做日志）

**是谁的日志**：InnoDB 存储引擎内部

**记录内容**：对数据页的「物理修改」，比如：

* 某个数据页上偏移多少字节写入了什么
* 是为了保证：崩溃后可以「重做到最新提交状态」

**主要用途**：

1. **崩溃恢复（Crash Recovery）**
   * 事务提交后，只要 redo log 持久化到了磁盘，即使数据页还没刷盘，宕机重启时：
     * 扫描 redo log，把已提交事务对应的修改「重做」到数据页；
     * 保证不会丢失已提交事务。

2. **支持 WAL（Write-Ahead Logging）**
   * 先写 redo log，再刷数据页；
   * 减少随机 IO，将随机写转成顺序写 log。

**特点**：

* 物理日志，记录「对哪一页做了怎样的修改」；
* 循环写（固定大小的 redo log 文件组）；
* 与 **binlog 无法互相替代**：redo 只在本机恢复使用，不能直接拿去做主从复制。

---

## 3\. undo log（回滚日志）

**是谁的日志**：InnoDB 存储引擎内部

**记录内容**：**数据被修改前的旧值**，可以理解为「逆操作」。

**主要用途**：

1. **事务回滚**
   * 事务未提交前，如果执行 `ROLLBACK` 或崩溃导致回滚：
     * InnoDB 通过 undo log 把已经修改的数据「恢复到修改之前」。

2. **MVCC（多版本并发控制）**
   * InnoDB 的 `REPEATABLE READ` 等隔离级别里：
     * 读操作需要看到某个「历史版本」；
     * 会沿着 undo log 链找到事务开始时的一致性快照。

**特点**：

* 逻辑上是对每行的「旧版本链」；
* 提交后并不会立即删除，对应版本仍可能被其他事务读取（历史快照）；
* 有后台 purge 线程清理已无读者依赖的旧 undo 版本。

---

## 4\. 三者协同（以一个事务为例）

假设你执行一条事务：

```sql
BEGIN;
UPDATE t SET c = c + 1 WHERE id = 1;
COMMIT;
```

大致流程是：

1. **执行 UPDATE 时**：
   * InnoDB 先写 **undo log**：记录这行修改前的值（用于回滚和 MVCC）。
   * 修改缓冲池里的数据页。
   * 生成对应的 **redo log** 记录「对数据页的物理修改」。

2. **事务提交前**：
   * MySQL Server 层生成本事务的 **binlog** 事件（比如 row 格式：这行从旧值变成新值）。

3. **两阶段提交（2PC）保证 binlog 与 redo 一致**：
   * InnoDB 先把 redo log 写入（prepare 状态）；
   * 写 binlog 并刷盘成功；
   * 再把 redo log 标记为 commit；
   * 任何时刻崩溃重启，都能根据 redo\+binlog 状态推断这笔事务该不该认为已提交。

4. **后续**：
   * 崩溃时：依赖 **redo log** 重做已提交事务；
   * 主从复制：依赖 **binlog** 重放；
   * 查询历史版本：依赖 **undo log** 做 MVCC；
   * 回滚未提交事务：依赖 **undo log** 撤销修改。



redo log：崩溃恢复 / 持久化 用的「重做日志」（物理日志，InnoDB 专用）

论mysql的三种log

数据库

MySQL中binlog用于主从复制和增量备份，记录逻辑变更；redolog用于崩溃恢复，记录物理修改；undolog用于事务回滚和MVCC，保存旧版本数据。三者协同确保数据一致性、持久化和并发控制。

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

论mysql的三种log-腾讯云开发者社区-腾讯云

论mysql的三种log

论mysql的三种log

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐