自动清理binlog最安全，mysql 8.0+推荐用binlog_expire_logs_seconds（如设为604800秒=7天），需写入my.cnf持久化；purge to按文件序号删，before按关闭时间删，误用易中断主从；reset master会清空所有binlog并重置索引，生产环境严禁使用。
自动清理 Binlog 是最安全的选择
MySQL 8.0+ 默认启用 binlog_expire_logs_seconds，它比已废弃的 expire_logs_days 更精确、更可靠。手动删日志容易误删正在被从库读取的文件，而自动策略由 MySQL 内部定时检查触发，只要配置得当，基本不会出问题。
- 先确认当前设置：
SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_seconds'; - 设为 7 天（604800 秒）：先清旧参数
SET GLOBAL expire_logs_days = 0;，再执行SET GLOBAL binlog_expire_logs_seconds = 604800; - 该配置不持久，需同步写入
my.cnf的[mysqld]段落，否则重启失效 - 修改后无需立即 purge，MySQL 会在下次 binlog 切换或每小时检查时自动清理过期文件；如需立刻触发，可执行
FLUSH LOGS;
PURGE BINARY LOGS TO 和 BEFORE 的区别与风险
这两个命令都直接删磁盘文件，但判断逻辑完全不同：前者按文件名序号截断，后者按文件最后修改时间截断——而这个“最后修改时间”是 binlog 文件**关闭时的时间戳**，不是你执行命令的那一刻。
-
PURGE BINARY LOGS TO 'mysql-bin.000025';删除所有序号 小于 000025 的文件（含 000024、000023…），000025 本身保留 -
PURGE BINARY LOGS BEFORE '2026-02-28 00:00:00';删除所有在该时间点前已关闭的 binlog 文件；注意：正在写的mysql-bin.000025即使创建于 2 月 27 日，只要没关闭，就不会被删 - 误用
BEFORE可能删掉主从同步还没拉完的日志，务必先查从库延迟：SHOW SLAVE STATUSG中看Seconds_Behind_Master和Read_Master_Log_Pos - 执行前建议先用
SHOW BINARY LOGS;确认文件列表和时间，避免输错序号或年份（比如把 2026 写成 2025）
RESET MASTER 不是清理，而是归零重来
RESET MASTER 会清空所有 binlog 文件并重置索引，相当于把 binlog “格式化”了。它不看保留策略、不检查从库状态、不写归档，执行后从库将无法继续同步——除非你重新搭建复制链路。
- 仅适用于单机开发环境、测试库、或明确要放弃所有复制关系的场景
- 生产环境绝对禁止在主库上直接运行，尤其当有多个从库或使用 GTID 时，会导致复制永久中断
- 执行后
SHOW BINARY LOGS;只剩一个新文件（如mysql-bin.000001），原文件全部从磁盘删除，不可逆 - 如果只是磁盘爆满想腾空间，优先选
PURGE或调小binlog_expire_logs_seconds，而不是RESET MASTER
从库上的 binlog 清理要单独处理
从库默认不生成 binlog（log_bin=OFF），但如果开启了 log_slave_updates，它就会像主库一样写 binlog，这部分日志也受 binlog_expire_logs_seconds 控制——但它的清理逻辑和主库完全独立，不会受主库 purge 影响。
- 从库上执行
PURGE BINARY LOGS只影响本地产生的 binlog，不影响主库或其他从库 - 若从库同时作为下级主库（级联复制），务必确认下游从库已同步完待删日志，再清理
- 腾讯云等托管数据库可能限制
PURGE权限，此时只能靠调整binlog_expire_logs_seconds静默清理 - 用
rm -rf直接删 binlog 文件是危险操作：MySQL 不知道文件没了，SHOW BINARY LOGS仍会列出已删文件，后续FLUSH LOGS可能报错或导致索引错乱
真正麻烦的从来不是“怎么删”，而是“删完谁还在用”。主从延迟、GTID 位点、备份工具依赖的 binlog 范围——这些信息藏在不同地方，不查清楚就动手，删的是空间，丢的是恢复能力。