mysql 8.0 默认不自动清理binlog，需配置binlog_expire_logs_seconds和binlog_expire_logs_auto_purge=on；检查用show variables，清理用purge binary logs to，禁用expire_logs_days。
MySQL 8.0 默认永不清除 binlog，必须显式配置 binlog_expire_logs_seconds 并确保 binlog_expire_logs_auto_purge 为 ON，否则磁盘迟早被撑爆。
确认当前清理策略是否生效
别凭配置文件猜，进 MySQL 实时查：运行 SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; —— 若返回 0 或 NULL，说明自动清理完全关闭；再查 SHOW VARIABLES LIKE 'binlog_expire_logs_auto_purge';，必须是 ON，否则设了秒数也白搭。顺手执行 SHOW BINARY LOGS; 看总大小，超 2GB 就该动手了。
永久配置 binlog_expire_logs_seconds（不是 expire_logs_days）
MySQL 8.0.11+ 已彻底弃用 expire_logs_days，设了不仅不生效，还可能触发错误 [3683]。正确做法是：
- 编辑你的 MySQL 配置文件（宝塔用户通常是
/www/server/mysql/etc/my.cnf，非/etc/my.cnf） - 在
[mysqld]段末尾添加两行：binlog_expire_logs_seconds = 604800binlog_expire_logs_auto_purge = ON - 若之前写过
expire_logs_days，务必删掉或注释掉，避免隐性冲突 - 保存后必须重启服务：
systemctl restart mysqld，热加载不支持该变量
手动触发清理或应急 purge 前必须核对从库状态
自动配置只管“未来”，已堆积的旧日志不会自动删；磁盘告急时得手动干预，但误删一条就断主从：
- 先在每个从库执行
SHOW SLAVE STATUS\G，记下Relay_Master_Log_File值（如mysql-bin.000120） - 取所有从库中该字段的最早序号（比如
.000120、.000125、.000123→ 安全边界是.000120） - 主库执行
PURGE BINARY LOGS TO 'mysql-bin.000120';（注意：不删.000120本身） - 想立刻触发自动清理逻辑，补一句
FLUSH LOGS;，它会强制轮转并扫描过期文件
为什么 PURGE BINARY LOGS BEFORE 很容易踩坑
BEFORE 删的是“已关闭” binlog 的最后修改时间戳，这个时间不是创建时间，也不是当前时间，而是文件关闭时写入的时间——你根本看不到，也很难校准。而 TO 按文件名序号删，逻辑清晰、可预测：
-
PURGE BINARY LOGS TO 'mysql-bin.000200';→ 删所有序号 000001～000199） - 执行前务必先
SHOW BINARY LOGS;确认目标文件存在，避免输错序号（比如把000200写成00020） - 绝对不要用
RESET MASTER，它清空全部 binlog 并重置序列号，从库全中断，不可逆
真正容易被忽略的是：binlog_expire_logs_seconds 只对「非当前正在写的 binlog」生效，不会动 mysql-bin.000xxx 这种活跃日志；而 max_binlog_size 控制单个文件大小，两者得配着用，否则单个文件过大可能导致清理滞后或备份卡顿。
