MySQL binlog清理需坚持“删得准、留得稳、管得住”，优先配置binlog_expire_logs_seconds自动清理，辅以手动PURGE前校验主从位置，再通过调小max_binlog_size、启用MINIMAL行格式等归档优化源头控量，并常态化监控告警。
MySQL 的 binlog 文件持续增长，确实容易导致磁盘空间紧张，甚至影响主从同步和备份恢复。关键不是“删得快”，而是“删得准、留得稳、管得住”。下面从清理和归档两个维度，给出可直接落地的操作要点。
自动清理：设好时间阈值，让 MySQL 自己干活
这是生产环境首选方式，安全、低干预、可持续。
- MySQL 8.0+ 用 binlog_expire_logs_seconds（单位秒），比如保留 7 天： SET GLOBAL binlog_expire_logs_seconds = 604800;
- 务必先清空旧的 expire_logs_days（设为 0），避免参数冲突： SET GLOBAL expire_logs_days = 0;
- 写入配置文件
/etc/my.cnf的[mysqld]段并重启，才能持久生效：
[mysqld] binlog_expire_logs_seconds = 604800 expire_logs_days = 0
设置后无需手动触发，MySQL 的 purge 线程会定期扫描并清理。如需立即见效，可执行 FLUSH LOGS; 切换新 binlog，加速旧日志释放。
手动清理：只在必要时精准操作，严防误删
适用于紧急腾空间、迁移前清理、或验证自动策略是否生效。操作前必须确认从库已追平。
- 查当前主库正在写的 binlog：SHOW MASTER STATUS;
- 查所有从库延迟和读取位置：SHOW SLAVE STATUS\G，重点关注 Relay_Master_Log_File 和 Exec_Master_Log_Pos
- 确保待删文件名早于所有从库的 Relay_Master_Log_File，再执行：
PURGE BINARY LOGS BEFORE '2026-02-28 00:00:00';
注意：时间格式必须是 YYYY-MM-DD HH:MM:SS，文件名序号不能错，严禁删除 正在被主库写入 或 从库尚未读取 的 binlog。
归档优化：控大小、降体积、减碎片
清理只是治标，控制单个文件体积和内容粒度，才能从源头缓解压力。
- 调小 max_binlog_size（默认 1GB），建议设为 100M–500M，避免单个文件过大拖慢备份和解析
- ROW 格式下启用 binlog_row_image = MINIMAL，只记录实际变更字段，大幅缩减日志体积
- 开启 binlog_rows_query_log_events = ON，保留原始 SQL（便于审计和问题回溯），不增加存储负担
- 预分配缓存：适当增大 binlog_cache_size（如 4M），减少频繁分配开销
监控与验证：别等报警才看，日常就要盯住
清理不是一劳永逸，要建立常态化检查习惯。
- 查当前 binlog 列表及大小：SHOW BINARY LOGS;
- 确认配置已生效：SHOW VARIABLES LIKE 'binlog%';
- 核对磁盘占用：du -sh /var/lib/mysql/binlog.*（路径依实际配置）
- 建议每天定时脚本检查 binlog 总量，超阈值（如 >20GB）自动告警
