安全清理MySQL binlog只能用PURGE BINARY LOGS或启用binlog_expire_logs_seconds自动清理；需确认binlog_expire_logs_auto_purge=ON且binlog_expire_logs_seconds>0，手动清理前须核对从库Relay_Master_Log_File并使用PURGE TO而非BEFORE，执行前务必SHOW BINARY LOGS;留证。
直接删 mysql-bin.* 文件会崩库或断主从，必须用 PURGE BINARY LOGS 或启用 binlog_expire_logs_seconds 自动清理——这是唯一安全路径。
确认当前自动清理是否生效
MySQL 8.0 不再依赖 expire_logs_days，它已被弃用。真正起作用的是 binlog_expire_logs_seconds 和开关 binlog_expire_logs_auto_purge：
-
SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_seconds';—— 若返回0，表示过期逻辑关闭；若为2592000（30 天），说明默认启用 -
SHOW GLOBAL VARIABLES LIKE 'binlog_expire_logs_auto_purge';—— 必须是ON，否则即使设了秒数也白搭 - 注意参数优先级：
binlog_expire_logs_auto_purge>binlog_expire_logs_seconds>expire_logs_days；三者冲突时，低优先级值会被忽略并报警告
手动清理前务必检查从库状态
误删正在被从库读取的 binlog 会导致复制中断，且无法自动恢复：
- 在主库执行
SHOW SLAVE STATUS\G，重点看Relay_Master_Log_File字段值（例如mysql-bin.000123） - 再查主库当前 binlog 列表：
SHOW BINARY LOGS;，确认Relay_Master_Log_File是否仍在列表中、且不是最旧的那个 - 若从库延迟大（
Seconds_Behind_Master很高），不要急着 purge；先等同步追上，或改用PURGE BINARY LOGS TO 'mysql-bin.000124';（保留该文件及之后所有）
用 PURGE 命令删比用时间更稳妥
BEFORE 按文件“关闭时间”删，但这个时间戳不直观，容易误判；TO 按文件名序号删，逻辑清晰、可预测：
-
PURGE BINARY LOGS TO 'mysql-bin.000200';—— 删除所有序号 小于000200的文件（即000199及更早），000200本身保留 - 执行前先
SHOW BINARY LOGS;确认目标文件存在，避免输错序号（比如把000200写成00020） - 不推荐用
PURGE MASTER LOGS BEFORE '2026-06-01 00:00:00';，除非你刚FLUSH LOGS过且清楚每个文件的关闭时间
临时设置后要立刻 flush logs 才能触发清理
动态设置 SET GLOBAL binlog_expire_logs_seconds = 604800; 不会马上删文件，MySQL 只在三个时机检查过期：启动时、FLUSH LOGS 时、或当前 binlog 文件写满触发切换时：
- 想立刻释放空间，必须补一句：
FLUSH LOGS; - 该命令会强制生成新 binlog 文件（如从
mysql-bin.000200切到mysql-bin.000201），同时触发对旧文件的过期扫描和删除 - 生产环境建议加进 crontab：
0 2 * * * mysql -e "FLUSH LOGS;"，确保每天至少触发一次清理逻辑
最易被忽略的一点：PURGE BINARY LOGS 是立即生效、不可回滚的 DDL 操作，没有事务包装。删错就只能靠备份恢复——所以每次执行前，先 SHOW BINARY LOGS; 截图留证，比什么都实在。
