MySQL中的binlog日志

一、什么是binlog？

binlog（二进制日志）是MySQL用来记录所有数据变更操作的文件。

就像一个"监控录像"，MySQL把每一个INSERT、UPDATE、DELETE操作都记录下来。

二、为什么需要binlog？

想象一个场景：你的电商系统突然宕机了，已经处理的订单数据丢失。这时候有了binlog就像有了"黑匣子"，你可以用它来恢复丢失的数据。

2-1、binlog的主要用途有三个：

1. 数据恢复 - 系统故障时，可以用binlog恢复到某个时间点的数据状态

2. 主从复制 - 从库通过读主库的binlog来保持数据同步。这是构建高可用系统的基础

3. 审计追踪 - 可以查看谁在什么时间修改了什么数据

2-2、binlog的三种格式

1、STATEMENT格式（记录SQL语句）

复制代码

比如你执行：UPDATE users SET age = age + 1 WHERE id > 100
binlog就记录这条SQL语句原文

优点：记录量小，节省空间

缺点：某些函数（如NOW()）可能导致从库数据不一致

2、ROW格式（记录行数据变化）

复制代码

不记录SQL语句，而是记录"id=101的用户age字段从20变成21"
详细记录每一行数据变化前后的值

优点：最安全，不会有数据不一致的问题

缺点：记录量大，占用空间多

3、MIXED格式（混合模式）

复制代码

MySQL智能选择：普通操作用STATEMENT格式，可能有问题的操作用ROW格式

三、如何启用binlog？

编辑MySQL配置文件 my.cnf：

bash 复制代码

[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin
binlog-format = ROW
expire-logs-days = 7

然后重启MySQL服务。

四、实际操作示例

查看binlog是否启用：

复制代码

SHOW VARIABLES LIKE 'log_bin';
-- 结果：ON 表示已启用

查看当前binlog文件列表：

复制代码

SHOW BINARY LOGS;
-- 显示：mysql-bin.000001, mysql-bin.000002 等

查看binlog内容（以可读的方式）：

复制代码

mysqlbinlog /var/log/mysql/mysql-bin.000001

输出会显示类似这样的内容：

bash 复制代码

# at 154
#250107 10:30:45 server id 1  end_log_pos 235
  Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1704597045/*!*/;
INSERT INTO users (id, name, age) VALUES (1, 'Alice', 25)

4-1、一个完整的场景理解

假设你有个电商系统：

复制代码

10:00 - 用户购买商品，订单状态改为"已支付"
10:05 - 系统宕机了
10:10 - 系统恢复，但这5分钟的数据丢了

此时你可以：
1. 查看binlog中10:00-10:05的所有操作
2. 用mysqlbinlog工具恢复这部分数据
3. 系统恢复正常

五、三个日志的作用

undo log ：用于事务回滚，记录数据修改前的旧值
redo log ：用于崩溃恢复，记录数据修改后的新值
binlog：用于主从复制和数据恢复，记录所有数据变更

5-1、三种日志的层次归属

日志类型	所属层次	文件后缀	负责模块
Binlog	Server层	`.000001`, `.000002`...	MySQL Server
Undo Log	存储引擎层 (InnoDB)	`ibdata1`, `undo001`	InnoDB 引擎
Redo Log	存储引擎层 (InnoDB)	`ib_logfile0`, `ib_logfile1`	InnoDB 引擎

5-2、详细对比三种日志

1. Binlog（二进制日志）

归属：Server层（所有引擎共用）

作用：主从复制 + 数据恢复

特点：

• 逻辑日志：记录SQL语句或行变化（ROW格式记录变化前后的值）

• 追加写入：一直往后写，文件满了切下一个

• 所有引擎共享：不管用InnoDB还是MyISAM，都会记录

为什么 Binlog 在 Server 层？

设计目标：支持所有存储引擎的主从复制

2. Undo Log（回滚日志）

归属：存储引擎层（InnoDB特有）

作用：事务回滚 + MVCC多版本控制

特点：

• 物理日志：记录数据修改前的旧版本
• 循环使用：空间会被复用

• 实现MVCC：提供事务的隔离性（可重复读）

3. Redo Log（重做日志）

归属：存储引擎层（InnoDB特有）

作用：崩溃恢复 + 保证持久性

特点：

• 物理日志：记录数据页的物理变化
• 循环写入：固定大小文件循环写

• Write-Ahead Logging：先写日志，后写数据

为什么 Redo/Undo 在引擎层？

设计目标：事务实现是引擎自己的事

不同引擎的事务实现不同：

• InnoDB：需要 Redo/Undo

• MyISAM：根本没有事务，不需要这些日志

只有 InnoDB 需要 Redo/Undo Log 吗？

是的！

MyISAM：没有事务，崩溃可能丢数据
Memory：数据在内存，重启就丢