当磁盘告警响起，很多人的第一反应就是检查 binlog。但别急着删除文件——务必先确认位置，再执行清理操作。在 MySQL 8.0 及以上版本中，expire_logs_days 参数已被废弃，必须使用 binlog_expire_logs_seconds（例如设置为 604800 秒）。如果两个参数同时存在，旧的配置可能引发冲突或失效。核心原则：先查看主从同步位置，再使用 PURGE 指令，切勿直接 rm 删除 binlog 文件。
确认 binlog 是否真的在快速增长，以及谁是真正的元凶
磁盘空间耗尽不一定就是 binlog 导致的。就在 2026 年 4 月，曾有一个案例中 slow_query_log 单独增长到了 397 GB。先彻底排查日志占用的空间：
- 使用
du -sh /var/lib/mysql/*.log /var/log/mysql/*.log扫描各个日志文件的大小，重点关注mysql-bin.*、slow-query.log、error.log。 - 执行
SHOW VARIABLES LIKE 'log_bin';确认 binlog 是否已开启——返回ON才算启用。 - 运行
SHOW BINARY LOGS;查看当前 binlog 文件总数和总大小。如果单个mysql-bin.000xxx超过 1 GB，并且文件数量持续增加，基本可以确定是 binlog 导致的问题。 - 别忘了检查
general_log是否被误开启：SHOW VARIABLES LIKE 'general_log';——这个日志会记录每一条 SQL，不使用时应务必关闭。
紧急释放空间：PURGE 前必须核对主从同步位置
直接 rm mysql-bin.000042 会导致主从同步中断，从库会报错 Got fatal error 1236。安全清理的前提是确认所有从库都已经读取完待删除的日志：
- 在主库执行
SHOW MASTER STATUS;，记录下File字段（例如mysql-bin.000042）。 - 逐一登录每个从库，执行
SHOW SLAVE STATUS\G，重点查看Relay_Master_Log_File和Exec_Master_Log_Pos。 - 找出所有从库中
Relay_Master_Log_File序号最小的那个（例如mysql-bin.000035），这就是安全边界——你最多只能执行PURGE TO 'mysql-bin.000036';。 - 执行清理命令：
PURGE BINARY LOGS TO 'mysql-bin.000036';或PURGE BINARY LOGS BEFORE '2026-06-02 00:00:00';（时间格式必须为Y-m-d H:i:s）。
防止反复爆满：MySQL 8.0+ 必须配置 binlog_expire_logs_seconds
从 MySQL 8.0 开始，expire_logs_days 已经废弃，默认值为 0（永不清除），即使设置了也可能不生效。仅使用 SET GLOBAL 是临时生效的，重启后就会丢失。
- 进入配置文件（如
/etc/my.cnf或宝塔路径/www/server/mysql/etc/my.cnf），在[mysqld]段添加：
binlog_expire_logs_seconds = 604800 expire_logs_days = 0
systemctl restart mysqld。SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; ——返回的值必须是你设置的秒数（如 604800），不能是 0 或空。max_binlog_size = 100M，防止单个 binlog 文件过大而拖慢 PURGE 效率。源头控量：别只盯着清理，还要压缩生成量
自动清理只是兜底措施，真正治本的方法是减少 binlog 本身的体积。
- 查看当前 binlog 格式：
SHOW VARIABLES LIKE 'binlog_format';——如果是ROW或MIXED，在高频更新场景下，体积可能是STATEMENT的 10 倍以上。 - 如果业务允许（无非确定性函数如
NOW()、RAND()），可以改用STATEMENT：SET GLOBAL binlog_format = 'STATEMENT';，并写入 my.cnf 永久生效。 - 检查应用层是否存在低效操作：例如用循环逐条
INSERT代替批量INSERT ... VALUES (...), (...)，这种写法会成倍放大 binlog 事件数。 - 对大表执行全量更新或删除前，评估是否可以分批执行并加限流措施，避免单次操作生成超大的 binlog 文件。
最容易被忽略的一点是：配置已修改、PURGE 也已执行，但磁盘空间却没有释放——这通常是因为旧日志文件的句柄仍被 mysqld 进程占用。此时需要执行 FLUSH LOGS; 强制切换新的 binlog 文件，旧文件才能被彻底释放。
