当前位置：首页 >域名 >图解 MySQL 日志体系：让你明明白白记住各种 Log

图解 MySQL 日志体系：让你明明白白记住各种 Log

发表于 2025-11-05 09:38:41 来源：全栈开发

面试官：MySQL的图解日志系统了解吗？

我：MySQL有binlog、redo log...

面试官：那它们分别解决什么问题？志体为什么需要这么多种日志？

我：这个...（尴尬）

相信这样的对话很多同学都经历过。大家都知道MySQL有各种日志，系让但要说清楚它们的明明作用和关系，往往就不那么容易了。白白

作为一名有着7年MySQL开发经验的记住老兵，今天我用最通俗的各种语言，帮你彻底理解MySQL日志体系。图解

一、志体为什么MySQL需要日志系统？系让

让我们从一个最基础的数据库操作说起：

复制// 用户消费100元 UPDATE account SET balance = balance - 100 WHERE id = 1;1.2.

这条简单的SQL语句，实际上给数据库带来了三大挑战：

可靠性问题：如果数据库突然宕机，明明这笔交易记录会不会丢失？白白一致性问题：如果用户要求退款，如何安全地回滚这笔交易？记住同步问题：如何确保其他数据库节点也正确记录了这笔交易？

为解决这些问题，MySQL设计了三种核心日志：

复制数据库操作 ──────────────────┐ ↓ ┌─── Redo Log（临时记事本） │ 记录："账户1减少100元" │ 作用：确保交易记录不丢失 │ ├─── Undo Log（原始凭证） │ 记录："账户1原有500元" │ 作用：随时可以撤销交易 │ └─── Binlog（总账本）记录："完整交易记录" 作用：用于数据同步和备份1.2.3.4.5.6.7.8.9.10.11.12.13.

二、各种重做日志（Redo Log）：数据库的图解"草稿纸"

1. 场景：会计小徐的烦恼

超市收银员小徐要记录1000笔交易。

传统方式（没有Redo Log）：

复制-- 每笔交易都要立即写入硬盘 UPDATE accounts SET balance = balance + 100; UPDATE products SET stock = stock - 1; 结果： ┌─────────────────────┐ │ ❌ 频繁随机写入硬盘 │ │ ❌ I/O效率极低 │ │ ❌ 系统性能下降 │ └─────────────────────┘1.2.3.4.5.6.7.8.9.10.

Redo Log的解决方案：

复制1. 先写入速记本（Redo Log） ┌────────────────────┐ │ 交易1: +100元,-1件 │ │ 交易2: +200元,-2件 │ ➜ 顺序写入，速度快 │ ... │ └────────────────────┘ 2. 数据先放内存 ┌────────────────┐ │ 内存中快速汇总 │ ➜ 响应迅速 └────────────────┘ 3. 定期整理同步 ┌────────────────┐ │ 批量写入硬盘 │ ➜ 提高效率 └────────────────┘1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16. 2. Redo Log工作原理详解

以顾客购买2箱牛奶为例：

复制// 顾客买了2箱牛奶（每箱100元） UPDATE accounts SET balance = balance + 200; UPDATE stock SET quantity = quantity - 2;1.2.3.

步骤1：速记本记录（Redo Log）

在Redo Log中记录交易信息：

交易编号

时间

操作类型

表名

修改内容

状态

001

09:01:01

UPDATE

accounts

账户余额+200

已记录

002

09:01:01

UPDATE

stock

牛奶库存-2

已记录

特点：

顺序写入：像流水账，效率高记录简单：快速记录交易信息

步骤2：临时汇总（内存）

在内存中快速更新数据：

账户

余额

现金

1200

商品

库存数量

牛奶

特点：

快速更新：客户立即看到结果数据在内存中：但断电会丢失

步骤3：持久化阶段，定期刷盘

在以下时机将数据写入硬盘：

营业员交接班时系统空闲时速记本快写满时固定时间间隔

Redo Log 工作流程图：

三、回滚日志（Undo Log）：数据库的香港云服务器"后悔药"

1. 场景：超市的退货处理

传统退货方式（没有Undo Log）：

顾客：我要退刚买的牛奶

小徐：抱歉，我们没记录原价，不知道该退多少钱...

现代方式（使用Undo Log）

顾客：我要退刚买的牛奶

小徐：好的，让我查看下交易记录

找到原始购买记录确认购买价格是100元确认库存状态可以安全退货2. Undo Log 工作原理详解

场景：用户下单扣款

复制// 顾客购买2箱牛奶 UPDATE accounts SET balance = balance + 200; // 收款200元 UPDATE stock SET quantity = quantity - 2; // 库存减21.2.3.

交易记录阶段（Undo Log记录）

编号

时间

表名

修改前数据

修改后数据

回滚指针

T001

09:01:01

accounts

balance=1000

balance=1200

-> T000

T002

09:01:01

stock

quantity=100

quantity=98

-> T001

T003

09:05:30

accounts

balance=1200

balance=1000

-> T002

T004

09:05:30

stock

quantity=98

quantity=100

-> T003

数据版本链（MVCC实现）：

Undo Log 工作流程图：

3. Undo Log的两大作用

(1) 支持事务回滚

记录数据修改前的状态支持出错时回滚保证事务原子性

(2) 实现MVCC（多版本并发控制）

不同事务看到不同版本的数据提高并发性能避免加锁带来的性能问题

四、二进制日志（binlog）：数据库的"保险箱"

1. 场景：连锁超市的账务管理

小徐是连锁超市的总经理，每天要处理这些数据管理问题：

复制场景一：商品管理总店：上架100种新商品 ┌─────────────────┐ │ 商品1: 牛奶 │ │ 商品2: 面包 │ ➜ 分店：一个个手动添加？ │ ...100条记录... │ └─────────────────┘ 场景二：数据安全 ┌─────────────────┐ │ 昨日销售数据 │ ➜ 系统崩溃，数据丢失！ └─────────────────┘ 场景三：变更追踪老板：这个商品谁改的价格？小徐：¯\_(ツ)_/¯ 不知道...1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.

而有了Binlog（二进制日志）后：

复制MySQL Binlog ├── 自动同步 │ 总店改价格 ──➜ 所有分店秒级更新 │ ├── 数据保护 │ 系统崩溃 ──➜ 从日志恢复数据 │ └── 操作追踪谁改了价格？──➜ 查看变更历史1.2.3.4.5.6.7.8.9. 2. Binlog的记录格式：如何记录数据变更？

让我们看看Binlog是如何记录数据变更的：

复制-- 一笔简单的商品价格调整 UPDATE products SET price = 98 WHERE name = 牛奶;1.2.

这条SQL语句在Binlog中有三种不同的记录方式：

(1) STATEMENT格式：记录SQL语句

复制# 直接记录SQL UPDATE products SET price = price * 0.9 WHERE category = 饮品; 优势：日志量小风险：可能导致主从不一致（比如NOW()函数）1.2.3.4.5.6.

(2) ROW格式：记录数据变化

复制{ "before": {"id": 1, "name": "牛奶", "price": 100}, "after": {"id": 1, "name": "牛奶", "price": 90} } 优势：数据准确特点：日志量较大1.2.3.4.5.6.7.

(3) MIXED格式：智能选择

复制# 根据SQL类型自动选择格式简单UPDATE：使用STATEMENT 复杂函数：使用ROW1.2.3.