mysql 8.0 必须用 binlog_expire_logs_seconds，expire_logs_days 已废弃且设之会报错；配置仅管控新日志，旧 binlog 需手动 purge 清理，并确认 binlog_expire_logs_auto_purge=on 才生效。
MySQL 8.0 必须用 binlog_expire_logs_seconds，设 expire_logs_days 会直接报错 ERROR 3683，且已堆积的 binlog 不会自动删——配置只是管“未来”，旧文件得手动清理。
确认当前生效的过期参数
连上 MySQL 后先查真实值，别信配置文件里写了什么：
-
SHOW VARIABLES LIKE 'log_bin';确保是ON（否则没 binlog 可谈） -
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';查秒级参数是否为非零值；若返回0或空，说明未启用自动清理 -
SHOW VARIABLES LIKE 'binlog_expire_logs_auto_purge';必须是ON，否则即使设了秒数也无效 - 如果
expire_logs_days值非零，先清掉：SET GLOBAL expire_logs_days = 0;，避免冲突
永久设置 binlog_expire_logs_seconds
临时 SET 只活到重启，磁盘爆满往往就发生在重启后——必须落盘：
- 编辑配置文件：
/www/server/mysql/etc/my.cnf（宝塔路径）或/etc/mysql/mysql.conf.d/mysqld.cnf（通用路径） - 在
[mysqld]段末尾添加：binlog_expire_logs_seconds = 604800（7 天） - 保存后重启：
systemctl restart mysqld或用宝塔面板操作 - 验证：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';应返回你写的数值，不是默认2592000
PURGE BINARY LOGS 手动清理已有堆积
配置只影响新生成日志，已存在的几十个 mysql-bin.000xxx 文件不会自动消失。误删会断主从，必须核对：
- 主库执行：
SHOW MASTER STATUS;记下当前File（如mysql-bin.000042） - 每台从库执行：
SHOW SLAVE STATUS\G，看Relay_Master_Log_File字段 - 取所有从库中序号最小的那个文件（比如
mysql-bin.000035），这就是安全底线 - 执行：
PURGE BINARY LOGS TO 'mysql-bin.000036';（删掉该文件之前所有） - 清理后
df -h若空间没释放，运行FLUSH LOGS;强制 MySQL 关闭旧句柄
宝塔脚本清理要绕过密码明文风险
计划任务里直接用 cat /www/server/panel/database/default.pl 读 root 密码，权限若非 600，其他用户可窃取——生产环境不能这么干：
- 创建专用账号：
CREATE USER 'cleaner'@'localhost' IDENTIFIED BY 'strong_pass'; - 只赋必要权限：
GRANT REPLICATION CLIENT, SUPER ON *.* TO 'cleaner'@'localhost'; - 建独立配置文件：
/www/server/panel/script/cleaner.cnf，内容为：
[client] user=cleaner password=strong_pass
- 设权限：
chmod 600 /www/server/panel/script/cleaner.cnf - 脚本里调用：
mysql --defaults-extra-file=/www/server/panel/script/cleaner.cnf -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"
真正容易被忽略的是：binlog_expire_logs_seconds 生效后，清理动作不是实时触发的，而是由后台线程每天凌晨检查一次；若磁盘已告急，必须手动 FLUSH LOGS + PURGE 组合操作，光靠配置救不了急。
