MySQL binlog日志查看与数据恢复实战：原理、命令与误操作追溯

先抛个问题：如果你的生产库某张表几千行数据在一个小时内被静默改掉了，你拿什么去追责、反查、恢复？很多人第一反应是看应用日志、看操作日志，但真正靠谱的答案其实是 MySQL 自己写下的那堆二进制日志——binlog。这个东西平时躺在数据目录里不起眼，等出了事才发现它比什么备份都金贵。这篇文章就围绕 mysql 查看 binlog 日志这件事，把 binlog 的原理、开启方式、查看命令、实战反查和恢复流程一次性讲透。

这篇文章适合所有维护 MySQL、或者工作中要对接 MySQL 的开发、运维、DBA，包括刚入门不久、被线上问题逼着去翻 binlog 的同学。不用急着背命令，先搞懂 binlog 到底记了什么，再上手操作，你会发现它其实就是数据库留给你的一本“流水账”，会读账本之后，误删恢复、主从排查、数据同步问题都会顺手很多。

1. binlog到底是什么：一个数据库“黑匣子”的自我修养

1.1 光靠binlog可不够：redo log、undo log和它的分工

很多刚学 MySQL 的人会把日志混为一谈，其实 InnoDB 引擎和 MySQL Server 层各写各的日志，核心就是三类：redo log、undo log、binlog。

redo log 是 InnoDB 引擎层的物理日志，记录的是“某个数据页被改成了什么样”，它是循环写的，磁盘上就那么几个文件，写完就覆盖。它的使命是保证崩溃恢复——数据库突然断电，内存里还没落盘的数据靠 redo log 重放，不会丢。注意，redo log 只关心崩溃那一刻的数据安全，不关心你历史上执行过哪些 SQL。

undo log 也是 InnoDB 层的，记录的是“改之前的数据长什么样”，用来支持事务回滚和 MVCC 多版本控制。你回滚一条 UPDATE，本质上就是拿 undo log 里的旧值把数据覆盖回去。但 undo log 是事务级的临时记录，事务一提交，历史版本就可能被清理掉，所以它也不适合做长期审计和恢复。

binlog 则是 Server 层的东西，和具体存储引擎无关。它记录的是数据库“发生了哪些逻辑变更”，是追加写，一个文件写满就换下一个，不会主动覆盖。只要你不手动清理，它会一直留着。它的价值可以概括成三个词：恢复、复制、审计。主从复制是靠它把主库的变更同步给从库；误删数据后可以用它把数据库回滚到某个时间点；出了安全事故时，可以用它追查到底是谁在什么时候改了哪条数据。

打个比方：redo log 是会计的草稿纸，画错了涂掉重来，只保证账目最终正确；binlog 是监控录像，一帧一帧记录着谁动了哪笔账，你随时可以回放查证。

1.2 binlog到底记了什么：从一条UPDATE说起

要理解 binlog 能查什么，先得知道它记录的内容形态。拿一条最简单的 UPDATE 举例：

sql复制UPDATE user SET age = 20 WHERE id = 1;

binlog 有几种记录格式，最常见的是 STATEMENT 和 ROW，后面会详细对比。在 STATEMENT 格式下，binlog 里直接记下这条 SQL 文本，主从复制时从库原样执行一遍。在 ROW 格式下，binlog 不记 SQL 文本，而是记“哪张表的哪一行发生了变化，旧值是什么、新值是什么”。对上面的 UPDATE，ROW 格式会记录 id=1 这一行的 age 从旧值变成了 20，还会记录其它列的完整值。

所以查询类语句如 SELECT、SHOW 是不会出现在 binlog 里的，这和你直觉里“日志就该记录所有操作”不太一样。如果你真想审计谁查了哪些数据，那得开通用查询日志 general_log，但那个日志线上一般不开，因为性能消耗大、文件膨胀快，而且记录的是客户端发过来的原始请求，量非常大。binlog 只在数据发生变更时才有存在感：INSERT、UPDATE、DELETE、DDL（CREATE TABLE、ALTER TABLE、DROP TABLE 等）都会记。

还有一个容易忽略的点：binlog 记录了事件发生的时间戳、执行事务的 server-id、事务的 GTID（如果开启了 GTID）、起始位置（position）等元信息。这些元信息是后面做精准定位的关键——你不仅能知道“改没改”，还能定位“在哪个日志文件、哪个偏移量开始的”。

2. 动手前先看两件事：binlog开没开、什么格式在写

2.1 三个命令确认当前状态

很多人查 binlog 时发现 SHOW BINARY LOGS 查不到任何文件，或者 mysqlbinlog 解析出来全是乱码，第一步就卡住了，原因往往是 binlog 根本没开，或者格式不对。上生产环境前，先用这三个命令摸清家底：

sql复制SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW BINARY LOGS;

log_bin 只有两个值 ON 或 OFF。如果是 OFF，下面所有操作都免谈，得先改配置开启。binlog_format 显示当前 binlog 的写入格式，常见值是 ROW、STATEMENT、MIXED。SHOW BINARY LOGS 会列出当前实例已经产生的所有 binlog 文件名和文件大小。

还有一个隐藏命令也很有用：

sql复制SHOW MASTER STATUS;

它返回当前正在写入的 binlog 文件名和当前写入位置（Position）。做全量备份、增量恢复时，这个值就是你的“水位线”——备份做到哪了、后续要从哪个位置开始补 binlog。

2.2 binlog_format三种模式怎么选

binlog_format 决定了 binlog 记录内容的粒度，这是很多实战问题的根源之一。三种模式对比如下：

生产环境我的建议是直接 ROW。原因很简单：主从复制一致性最可靠，误删恢复时也能拿到完整旧值。STATEMENT 格式虽然日志小，但一条 DELETE FROM t WHERE id > 100 在 STATEMENT 格式下只记录一句 SQL，而 ROW 格式会记录删除的每一行旧数据。真要恢复时，后者能让你精确知道删了哪些数据、原值是什么；前者只能告诉你“执行过这么一条 SQL”，具体影响哪些行还得靠猜。

MIXED 看起来很聪明，但它会在 SQL 级和 ROW 级之间跳动，跨文件解析时你需要同时处理两种形态，反而增加定位成本。没有特殊理由，不要在生产环境用 MIXED。

2.3 5.7和8.0的默认差异

不少人在 MySQL 5.7 上安装完就直接用，发现 log_bin 默认是 OFF，也不奇怪；但到了 MySQL 8.0，很多人什么都没配置，却发现数据目录里已经生成了 binlog 文件，于是跑来问“为什么我什么都没做也有 binlog”。

这是因为 MySQL 8.0 把 log_bin 的默认值改成了 ON，并且默认格式就是 ROW。也就是说，从 8.0 开始，官方替你默认开启了 binlog 这层保险。这本身是好事，但也带来一个新问题：如果你不知道 binlog 已经开了、也没配置自动清理，数据量大的库可能几天就把磁盘写满。8.0 默认的清理策略是 30 天自动过期（binlog_expire_logs_seconds 默认 2592000 秒），但前提是你没把自动清理关掉，删改参数时要小心。

5.7 和 8.0 在清理参数上也有区别：5.7 用的是 expire_logs_days，单位是天，默认 0 表示不过期；8.0 引入了 binlog_expire_logs_seconds，单位是秒，精度更高。这个差异会导致一个问题：如果你把 5.7 的配置原样搬到 8.0，expire_logs_days 在 8.0 里已经废弃，不生效。

2.4 开启binlog和参数调整

如果实例还没开 binlog，修改 my.cnf（Linux 通常是 /etc/my.cnf 或 /etc/mysql/my.cnf，Windows 是 my.ini）里的 [mysqld] 段，加上这样一组配置：

ini复制[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
expire_logs_days = 15

改完需要重启 MySQL 服务才能生效。这里有个容易踩的坑：开启 binlog 时必须配置 server-id，而且同一集群内每个节点的 server-id 不能冲突。你不配 server-id 直接开 log-bin，MySQL 可能起不来，或者复制链路出现各种奇怪报错。原因在于 binlog 文件里的每个事件都会带上 server-id，主从复制时靠它识别来源，没有身份标识，整个复制协议就跑不通。

8.0 上如果还想用按天过期，可以写成：

ini复制[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 1296000

这里的 1296000 秒等于 15 天。注意 binlog_file 前缀可以自定义，我习惯用 mysql-bin，这样文件会生成 mysql-bin.000001、mysql-bin.000002 这种命名，清晰好辨认。默认不指定前缀的话，会以主机名命名，比如 yourhost-bin.000001，在追查问题时不太容易一眼看出是哪个实例的日志。

还有一点：binlog_format 是可以在线动态改的，执行 SET GLOBAL binlog_format = 'ROW'; 后新写入的日志会按新格式来，但已经生成的 binlog 文件格式不会变。所以在线切换后，解析老文件仍然要按老格式去解析，排查时要特别留意文件的时间边界。

3. 查看binlog的三种打开方式：命令、事件、工具

3.1 SHOW BINARY LOGS：先知道有哪些文件

想查看 binlog，第一步永远是先看文件列表。SHOW BINARY LOGS; 的输出列包括 Log_name 和 File_size，前者是文件名，后者是文件当前大小。一般长这样：

text复制+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |      1024 |
| mysql-bin.000002 |     10240 |
+------------------+-----------+

文件大小能侧面反映业务写入量。如果某个文件异常巨大，说明那个时段有大事务或者大批量写入，这对后续定位很有参考价值。还有一个细节：binlog 文件不是在事务提交时立刻刷新的，它由参数 sync_binlog 控制刷盘策略，默认值是 1，表示每次事务提交都刷盘，最安全但性能有损耗；如果改成 0，数据库异常宕机时可能丢失最近的一部分 binlog 事件。排查问题时如果发现 binlog 里缺少最后几秒的操作，先检查这个参数。

3.2 SHOW BINLOG EVENTS：看某一文件里都有什么

知道文件名后，可以用 SHOW BINLOG EVENTS 查看文件内的事件列表。推荐配合 IN、FROM、LIMIT 三个关键字一起用：

sql复制SHOW BINLOG EVENTS IN 'mysql-bin.000003' LIMIT 5;
SHOW BINLOG EVENTS IN 'mysql-bin.000003' FROM 4 LIMIT 10;

输出列包括 Log_name、Pos、Event_type、Server_id、End_log_pos、Info。Pos 是事件起始位置，End_log_pos 是结束位置，两个值之间的区间就是这个事件在文件里的覆盖范围。Event_type 常见的有 Format_desc、Query、Table_map、Write_rows、Update_rows、Delete_rows、Rotate 等。看到 Write_rows、Update_rows、Delete_rows 就说明对应有插入、更新、删除操作。

这个命令适合快速扫一眼某个文件里大概有什么，但不适合做精确分析。原因有两个：一是 ROW 模式下事件内容会以 base64 编码显示，密密麻麻一大坨，人眼根本读不动；二是不支持按时间或表名过滤，文件一多你只能一个个翻，效率极低。真正的分析工作，得交给 mysqlbinlog 工具。

3.3 mysqlbinlog：把二进制日志“翻译成人话”

mysqlbinlog 是 MySQL 自带的命令行工具，也是查看 binlog 的核心武器。它的基本用法非常简单：

bash复制mysqlbinlog --no-defaults /var/lib/mysql/mysql-bin.000003

直接输出该文件的所有事件。如果你在生产环境执行过，大概率会看到大量类似 BINLOG '...' 的 base64 串，这就是 ROW 格式下的原始内容，不经过参数处理就是天书。想让它“说人话”，必须配合两个参数：

bash复制mysqlbinlog --no-defaults --base64-output=DECODE-ROWS -v /var/lib/mysql/mysql-bin.000003

参数 --base64-output=DECODE-ROWS 会把 ROW 事件中的 base64 内容解码成用 ### 开头的伪 SQL；-v 让输出包含行内容；再加一个 -v 变成 -vv，输出更详细，会显示每个字段的类型注释和可能的值。我建议直接 -vv，信息全，排查时少猜很多事。

mysqlbinlog 的常用参数远不止这些，列个表方便查阅：

--start-datetime 和 --stop-datetime 是时间范围过滤，--start-position 和 --stop-position 是位置范围过滤。两者的区别在于：时间过滤靠事件里的时间戳，如果服务器时钟有跳变或主从节点时间不一致，可能不准；位置过滤是绝对偏移量，最精确。所以能拿到位置就尽量不依赖时间。实际工作中我通常是先用时间范围扫一遍，找到关键事件的位置，再用位置范围精确定位。

如果 binlog 文件不在本机，也可以远程读取：

bash复制mysqlbinlog --no-defaults --read-from-remote-server --host=192.168.1.10 --user=monitor --password=xxx mysql-bin.000005

但不建议在生产环境直接远程拉大文件，网络开销和磁盘 IO 都不小。更稳妥的做法是把文件拷贝到本地或跳板机再解析。

4. 从binlog反查谁改过数据：一次误操作定位的完整过程

4.1 先想清楚：binlog里没有SELECT

很多人第一次用 binlog 反查数据问题时，会直接问“能不能查一下谁执行了 SELECT * FROM user”。答案是不能，因为 SELECT 不改变数据，binlog 不记录它。binlog 能回答的问题是：某张表的某些行，在什么时间，被 INSERT、UPDATE、DELETE 过，变更前后的值是什么。

有一个反直觉但重要的点：binlog 也不直接记录“是哪个应用账号执行的”，它记录的是执行这些操作的 MySQL 账号和 server-id。如果你用的是同一个业务账号连库，那 binlog 只能告诉你“这个账号在什么时间改了数据”，无法精确到“是哪个开发同事发的请求”。要追踪到具体人，得靠应用层日志、连接池记录、或者数据库审计插件，那是另一个话题了。

不过在绝大多数误操作场景里，binlog 已经足够用了。目标不是抓人，而是搞清楚“是什么 SQL 把数据弄坏的、影响哪些行、能不能恢复”。

4.2 定位时间段和日志文件

下面用一个真实场景走一遍完整流程。假设下午 14:30 接到反馈，订单表 order_info 的某个状态字段大面积被改成错误值，预估问题发生在 14:00 到 14:20 之间。

先在 MySQL 里确认 binlog 文件范围：

sql复制SHOW BINARY LOGS;

假设结果有 mysql-bin.000019 到 mysql-bin.000023。由于写操作集中在 14:00-14:20，极大概率落在后面一两个文件里。为了保险，直接解析所有文件并过滤时间段，用 mysqlbinlog 输出到临时文件：

bash复制mysqlbinlog --no-defaults --base64-output=DECODE-ROWS -vv \
  --start-datetime='2025-01-10 14:00:00' \
  --stop-datetime='2025-01-10 14:30:00' \
  /var/lib/mysql/mysql-bin.000021 > /tmp/events.sql

如果不知道具体是哪个文件，可以用循环解析多个文件并追加到同一个临时文件。然后在这个输出文件里搜索目标表名：

bash复制grep -n "order_info" /tmp/events.sql

在 ROW 模式下，mysqlbinlog 解析出的伪 SQL 会写成 ### UPDATE db_name.order_info`` 这样的格式，所以直接 grep 表名就能定位到事件所在的行号，再前后翻几十行看上下文。

4.3 把ROW模式日志还原成可读SQL

上面命令产出的内容，在 ROW 模式下大体会长这样：

text复制# at 184
#250110 14:05:03 server id 1  end_log_pos 356 CRC32 0x...  Query   thread_id=888  exec_time=0  error_code=0
SET TIMESTAMP=1742177103/*!*/;
BEGIN
/*!*/;
# at 256
#250110 14:05:03 server id 1  end_log_pos 404 CRC32 0x...  Table_map: `db_name`.`order_info` mapped to number 89
# at 404
#250110 14:05:03 server id 1  end_log_pos 520 CRC32 0x...  Update_rows: table id 89 flags: STMT_END_F
### UPDATE `db_name`.`order_info`
### WHERE
###   @1=10086 /* INT meta=0 nullable=0 is_null=0 */
###   @2='READY' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### SET
###   @2='CANCELED' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */

### UPDATE 下面的 ### WHERE 部分是变更前的旧值，### SET 部分是变更后的新值。@1、@2 分别对应表的第一列、第二列。但 mysqlbinlog 不会自动告诉你 @1 是 id、@2 是 status，因为 binlog 里不存列名，你得拿着建表语句去对照。

让我说清楚：在建表语句中，第一列是 id，第二列是 status，那这条事件翻译成人话就是“把 id=10086 这行订单的 status 从 READY 改成了 CANCELED”。如果嫌手工对照列名太累，可以用开源工具 binlog2sql，它连上 MySQL 实例读取表结构，自动把 @1、@2 翻译成列名，直接输出标准的 INSERT/UPDATE/DELETE 语句。我在定位大批量事件时一般先用 binlog2sql 粗筛，再用 mysqlbinlog 精读上下文。

4.4 顺着事件ID精确圈定影响范围

用时间范围过滤已经能定位到问题区间，但如果你想重放或恢复，就必须用 position 做精确边界。比如通过临时文件发现关键事件从 # at 184 开始，到你知道误操作结束的位置为止，就可以这样精确截取：

bash复制mysqlbinlog --no-defaults --base64-output=DECODE-ROWS -vv \
  --start-position=184 \
  --stop-position=8932 \
  /var/lib/mysql/mysql-bin.000021 > /tmp/precise.sql

--stop-position 怎么确定？常见做法是先用时间范围解析出一份完整文件，找到误操作事务结束的那个 # at 位置。事务结束通常对应 COMMIT 事件，它前面那个 # at 就是事务边界。把边界位置作为 --stop-position，能确保后续重放时不会把误操作带进去。

如果实例开了 GTID，binlog 每个事务都会带 GTID 标识，mysqlbinlog 输出里会出现 SET @@SESSION.GTID_NEXT='xxx' 这样的行。在恢复场景下，这些 GTID 信息可能导致重放时碰到“GTID 已执行过”的报错，因为目标实例已经记录过这些事务。解决办法是重放时加 --skip-gtids，让 mysqlbinlog 在输出中忽略 GTID 设置，只保留 SQL 内容。这是我第一次做 binlog 重放时踩过的坑，一定要记住。

还有一个提升效率的小技巧：如果怀疑误操作只涉及某张表，加 --database 参数可以把其它库的事件过滤掉，输出体积大幅缩小。但这个参数按库而不是按表过滤，所以如果你的库里同名的表很多，或者一个库内有多个业务表，还是得靠 grep 二次筛选。

5. 利用binlog做数据恢复：全量备份之外的增量拼图

5.1 恢复的核心思路：全量+增量

binlog 的最大价值不只是“看”，而是“恢复”。这里先说清楚一个概念：单靠 binlog 无法恢复完整数据，因为 binlog 只是增量日志，不是全量快照。正常的数据保护体系必须是“全量备份 + binlog 增量”。

恢复的思路是这样的：假设你每天凌晨 2:00 做一次全量备份，备份完成时记录当时的 binlog 文件名和位置（这步很关键，备份脚本里通常会自动记录，比如输出到备份目录下的一个文本文件）。今天下午 14:00 误删了数据，恢复流程就是：

1. 在一台临时实例上恢复最近一次全量备份，比如恢复到凌晨 2:00 的状态。
2. 把凌晨 2:00 到下午 14:00 之间、误操作发生之前的 binlog 事件按顺序重放到临时实例上。
3. 临时实例的数据就恢复到了误操作前的状态，再导出数据，处理干净后导回生产，或者直接切换。

整个过程用命令串起来大致是这样：

bash复制# 1. 把全备恢复到临时实例
mysql -uroot -p < /backup/full_backup.sql

# 2. 把指定时间段的 binlog 重放到临时实例
mysqlbinlog --no-defaults \
  --start-datetime='2025-01-10 02:00:00' \
  --stop-datetime='2025-01-10 14:00:00' \
  /var/lib/mysql/mysql-bin.000021 \
  | mysql -uroot -p -h 127.0.0.1

重放时用 --stop-datetime 或者更精确的 --stop-position 卡在误操作之前。如果误操作本身是个事务，position 定位可以精确到事务的 BEGIN 之前，重放时就不会带入那条错误 SQL。

5.2 重放binlog的注意事项

binlog 重放不是简单地把命令跑一遍就完事，实践中有几个问题必须提前处理：

第一，重放目标绝对不能是生产库。误操作恢复场景下，数据状态是不确定的，任何错误的 SQL 都可能造成二次伤害。一定先在临时实例上把整个恢复流程跑通，确认数据一致后再考虑回切。这个原则我在线下环境反复跟团队强调过，但还是有人图省事直接在生产上执行重放，结果又是一场事故。

第二，GTID 冲突问题。如果源实例和目标实例都开启了 GTID，重放时目标实例可能会因为“该事务的 GTID 已经在执行历史中”而跳过，导致数据根本没恢复。解决办法是重放时加 --skip-gtids 参数，让 mysqlbinlog 输出中带上 SET GTID_NEXT='AUTOMATIC'，相当于告诉目标实例“忽略源事务的 GTID，重新执行”。

第三，过滤业务库。生产库通常有多套业务，如果误操作只涉及某一个库，重放时加上 --database=db_name 只放指定库的事件，避免把其它库的旧操作也一并执行，减少冲突概率。

第四，大事务问题。binlog 里如果有超大事务（比如一次批量更新几百万行），重放时可能非常耗时，甚至超过临时实例的 undo 空间。遇到这种情况，可以先在临时实例上设置 innodb_flush_log_at_trx_commit=2、sync_binlog=0 这类参数提升写入速度，恢复完再改回去。恢复场景不是高并发业务环境，可以适度牺牲持久化来换速度。

我把这些整理成一个速查表：

5.3 不只是恢复：binlog还是数据同步的基石

binlog 在现代架构里还有一个越来越重要的角色：数据变更捕获。很多公司用 Canal、Debezium 等工具监听 binlog，把 MySQL 的增量变更实时同步到 Elasticsearch、Redis、Kafka 或数仓，实现数据异构。这类工具之所以能工作，正是因为 binlog 以 ROW 格式记录了每一行的变更前后值，下游系统能直接消费这些事件，更新自己的索引或缓存。

说到 DataX，它是离线同步工具，一般用于批量导入导出，本身不直接消费 binlog。但很多数据同步方案会把“DataX 做全量初始化 + Canal 解析 binlog 做增量同步”组合起来，先全量拉一次数据，再用 binlog 持续补增量。理解了 binlog 的定位，你也就理解了这类同步架构为什么能跑通。

所以即便你现在没遇到数据误删，binlog 也值得花时间搞清楚。它是 MySQL 生态里连接“数据库”和“外部世界”的关键管道，很多现代化数据系统的设计都建立在对 binlog 的依赖之上。

6. binlog文件管理与清理：别手贱rm，也别放任不管

6.1 binlog可以删，但要按规矩删

经常有人问“mysql8.0 binlog可以删除吗”。答案是：可以删除，但绝对不能用 rm 命令直接删文件。直接删 binlog 文件会踩一个大坑：MySQL 的 binlog.index 索引文件里还保留着被删文件的记录，SHOW BINARY LOGS 会报错，主从复制时从库也找不到对应日志，整个复制链路直接断掉。

正确的删除方式是用 MySQL 自带的清理命令：

sql复制-- 删除 mysql-bin.000010 之前的所有 binlog
PURGE BINARY LOGS TO 'mysql-bin.000010';

-- 删除 2025-01-01 之前的 binlog
PURGE BINARY LOGS BEFORE '2025-01-01 00:00:00';

这两个命令是安全的，MySQL 会在内部同步更新 binlog.index 索引，并且不会删除正在写入的当前文件。但注意，PURGE BINARY LOGS BEFORE 的时间判断是基于 binlog 事件时间，不是文件生成时间，所以如果你想保留某个指定时间段，最好先 SHOW BINLOG EVENTS 确认边界。

还有两个更危险的操作：RESET MASTER 和 RESET BINARY LOGS AND GTIDS。前者会把所有 binlog 文件清空并重新编号，一般在初始化实例时才会用，生产环境执行等于把你所有的历史审计日志一把火烧了；后者除清空 binlog 外还会重置 GTID 执行历史，影响主从复制，碰都不要碰。

6.2 自动清理参数怎么设

手工清理有个问题：人总会忘记。所以生产环境必须配置自动清理，靠参数控制 binlog 保留时间。

MySQL 5.7 用 expire_logs_days，单位是天。8.0 引入了 binlog_expire_logs_seconds，单位是秒，并且逐渐废弃了 expire_logs_days。两者对比：

设置自动清理时，单纯设一个时间是不够的，还要考虑全量备份周期。假设你每天凌晨做全量备份，那 binlog 保留时间至少要比全量备份周期长，最好留出 2-3 天的富余量，因为恢复时你需要“上一次全量备份之后到误操作之前”的 binlog。如果只保留 1 天，而备份是两周一次，那恢复时中间 13 天的 binlog 已经没了，只能恢复到上一次全量备份的状态，丢失大量数据。

还有一个经验值：磁盘空间占用按 binlog 平均增长速度来估算，比如每天产生 50GB binlog，磁盘有 2TB，那最多能撑 40 天。自动清理保留 7 天比较稳，既保证恢复窗口足够，又不会把磁盘打满。建议监控 SHOW BINARY LOGS 的总大小，超过阈值时告警。

6.3 binlog和从库、同步工具的联动

清理 binlog 时最容易忽略的是下游消费方。主库的 binlog 不只是给自己看的，从库的 IO 线程会持续从主库拉取最新日志；Canal 这类同步工具也会从某个 position 开始消费。如果主库清理得比下游消费进度还快，从库或同步工具就会报“找不到日志”的错误，然后从库复制中断，同步链路停止。

在从库或同步工具存在的情况下，正确的清理姿势是：先确认所有下游的消费位点，再决定删到哪个文件。从库的消费位点可以通过 SHOW SLAVE STATUS\G 查看（主要看 Master_Log_File 和 Read_Master_Log_Pos）；Canal 的消费进度在它的元数据表里也有记录。清理时保留的 binlog 至少要覆盖下游最新消费位点。稳妥起见，清理前看一眼下游进度，再把 PURGE BINARY LOGS TO 的目标文件设在其之后。

我自己在实际操作中的习惯是：把 binlog 当成和数据库数据一样重要的东西来管理，开启 ROW 格式、定期备份、自动清理留足恢复窗口、清理前确认下游消费位点。这四件事做下来，binlog 这层“保险”才能真正发挥作用。很多团队把 binlog 当成了可有可无的日志，结果一出事就要从零开始摸索恢复流程，那种痛苦我体验过不止一次。趁现在数据还好好的，先把这些命令和流程跑通，比什么都强。