必须显式配置binlog_expire_logs_seconds（8.0+）或expire_logs_days（5.7-），默认0表示永不清除；需写入my.cnf并重启生效，且binlog_expire_logs_auto_purge须为on。
MySQL Binlog 不设自动清理周期，磁盘空间迟早被撑爆——这不是预警，是已发生的事实。核心解决方式就一条：必须显式配置 binlog_expire_logs_seconds（MySQL 8.0+）或 expire_logs_days（5.7 及更早），且默认值为 0（永不清除）。
确认你用的是哪个过期参数
MySQL 8.0.11 起，expire_logs_days 已废弃；8.0.23+ 启动时即使写了也不会生效，还可能悄悄记一条 deprecation warning 到 error log（你大概率没开监控）。别猜，直接进 MySQL 查：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';<br>SHOW VARIABLES LIKE 'expire_logs_days';
如果 binlog_expire_logs_seconds 是 NULL 或 0，说明没启用自动清理；如果它返回一个正整数（比如 604800），那才是真正在管事。注意：expire_logs_days 显示的值可能是旧配置残留，不代表实际生效。
永久生效必须写进配置文件，不能只靠 SET GLOBAL
SET GLOBAL binlog_expire_logs_seconds = 604800 确实能立刻生效，但 MySQL 重启后就丢——生产环境绝不该依赖这个。正确做法是编辑你的 MySQL 配置文件（通常是 /etc/my.cnf 或 /www/server/mysql/my.cnf），在 [mysqld] 段下加一行：
binlog_expire_logs_seconds = 604800
改完之后：
- MySQL 8.0.11+ 必须重启服务才能加载该变量（不支持热加载）
- 顺手检查
binlog_expire_logs_auto_purge是否为ON（它是开关，优先级高于过期时间，设为OFF就全废了） - 可执行
FLUSH BINARY LOGS触发一次日志轮转，加速过期判断
PURGE 命令不是替代方案，而是应急补救手段
自动清理机制不是定时任务，而是靠 mysqld 在启动、日志轮转或每小时左右扫描触发。这意味着即使设了 7 天，也可能延迟几小时才删——磁盘告急时等不及。这时要用 PURGE BINARY LOGS 手动干预，但必须避开从库还在读的日志：
- 先在每个从库执行
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File值 - 取所有从库中该字段的最早序号（比如
mysql-bin.000120）作为安全边界 - 主库执行
PURGE BINARY LOGS TO 'mysql-bin.000120'（注意：不删.000120本身） - 绝对不要用
RESET MASTER——它会清空全部 binlog 并重置序列号，从库全中断
真正容易被忽略的点是：binlog_expire_logs_seconds 只对「非当前正在写的 binlog」生效，不会动 mysql-bin.000xxx 这种活跃日志；而 max_binlog_size 控制单个文件大小，两者得配着用，否则可能单个文件过大导致清理滞后或备份卡顿。
