MySQL binlog默认永不过期，易致磁盘爆满；需检查log_bin=ON、binlog_expire_logs_seconds=0（或未设）及expire_logs_days=0，并确保binlog_expire_logs_auto_purge=ON，8.0.23+必须用binlog_expire_logs_seconds设秒级保留。
一个必须正视的现实是：如果不对MySQL的binlog设置过期策略，它默认就是永久保存的。这意味着，磁盘空间被日志文件彻底撑爆，几乎是一个必然会发生的结果，而非什么小概率风险。
如何确认 binlog 是否已启用且未设过期时间
排查的第一步，是登录到MySQL实例，执行几个关键命令来摸清状况。
首先，确认binlog功能是否开启：SHOW VARIABLES LIKE 'log_bin'; 确认值为 ON；
接着，查看所有与过期相关的参数：SHOW VARIABLES LIKE '%expire%';
这里需要重点关注三个参数：
binlog_expire_logs_seconds：这是MySQL 8.0.23版本之后的主力参数。如果它的值是0或者干脆没设置，那就意味着“永不过期”。expire_logs_days：这是旧版本兼容的参数。默认值就是0，同样代表不清理。binlog_expire_logs_auto_purge：这个开关必须为ON，自动清理机制才会真正工作。
这里有个关键细节：如果 binlog_expire_logs_seconds 是0或未设置，那么即使你把 binlog_expire_logs_auto_purge 设为 ON，清理机制也形同虚设，不会生效。
MySQL 8.0.23+ 必须用 binlog_expire_logs_seconds 设置秒级保留
对于MySQL 8.0.23及之后的版本，情况发生了变化。新版本不再允许 expire_logs_days 和 binlog_expire_logs_seconds 两个参数共存，如果同时设置，会直接报错 ERROR 3683 (HY000)。所以，必须统一使用秒级参数来管理。
设置方法有两种：
动态设置（立即生效，但重启后丢失）：SET GLOBAL binlog_expire_logs_seconds = 604800;（这个例子是设置保留7天）
永久生效（写入配置文件）：
编辑MySQL配置文件，例如 /etc/my.cnf，在 [mysqld] 段落中添加：
binlog_expire_logs_seconds = 604800修改后需要重启MySQL服务。或者，如果你有相应权限，也可以执行
SET PERSIST binlog_expire_logs_seconds = 604800; 来持久化设置。
关于这个参数，有几个重要的操作特性需要了解：
- 它只负责设定“过期时间”，并不控制“单个文件的大小”。清理动作由MySQL的后台线程在每天凌晨触发，并非实时进行。
- 如果主从复制存在严重延迟，从库还未读取完毕的binlog文件，主库是不会删除的。因此，确保复制链路健康是前提。
- 参数设置后，不会立刻删除已有日志。如果想立即触发一次清理，可以手动执行
FLUSH LOGS;命令来轮转日志文件，然后等待后台清理线程运行。
max_binlog_size 控制单个 binlog 文件上限，但不解决总量问题
很多人会把 max_binlog_size 和过期策略混淆。其实，max_binlog_size 只决定每个binlog文件的最大体积（例如设为 536870912 就是512MB），文件写满后会自动切换到新文件。它的作用在于让日志文件更易于管理，避免单个文件过大影响备份或传输效率，但它完全无法控制磁盘上binlog文件的总量和留存时间。
实践中，常见的误操作包括：
- 只调大了
max_binlog_size，却没有设置binlog_expire_logs_seconds。结果就是日志文件数量变少了，但每个文件都巨大，磁盘占用总量依然会疯狂增长。 - 把
max_binlog_size设得过小（比如10MB）。这会导致文件切换极其频繁，不仅增加文件系统的开销，还会让SHOW BINARY LOGS这类查询的负担变重。 - 缺乏对磁盘使用率的监控，等到执行
df -h发现/var/lib/mysql分区使用率超过95%时，才手忙脚乱。
关于这个值的设置，通常建议在512MB到1GB之间，具体需要根据磁盘的I/O能力和业务归档的频率来权衡。
手动清理前务必确认从库同步状态
如果觉得自动清理不够及时，或者急需立刻释放磁盘空间，手动清理是一个选项。但手动操作 PURGE 命令前，有一项至关重要的检查绝对不能跳过：确认所有从库的同步状态。
操作流程如下：
首先，在主库上查看当前的binlog位置：SHOW MASTER STATUS;
然后，检查所有从库的同步进度：SHOW SLA VE STATUS\G（或者查询 SELECT * FROM performance_schema.replication_applier_status_by_coordinator;），核心是关注 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 这两个值。
安全清理的原则是：只有当所有从库的 Exec_Master_Log_Pos（已执行的位置）都大于你打算删除的那个binlog文件的结束位置时，这个文件才是可以安全删除的。否则，如果你执行了类似 PURGE BINARY LOGS BEFORE '2026-04-01 00:00:00'; 的命令，从库的IO线程很可能会立刻报错：Could not find first log file name in binary log index file，导致复制中断。
最后，还有一个极其容易被忽略的盲点：即使你的环境里没有配置传统的从库，也要排查是否有其他备份工具（例如mydumper、xtrabackup等）正在读取binlog。这些工具在备份时可能会隐式地依赖某一段日志，如果贸然删除，就会导致备份任务失败。
