MySQL binlog文件膨胀的根本原因是expire_logs_days默认为0，需在my.cnf中配置expire_logs_days（或8.0.11+用binlog_expire_logs_seconds）并重启，再执行PURGE BINARY LOGS手动清理旧日志，同时建议添加宝塔定时脚本兜底。
宝塔面板里 MySQL 的 mysql-bin.* 文件持续膨胀，根本原因不是配置漏了，而是 MySQL 默认不清理——expire_logs_days 默认值是 0，等于永久保留。关掉 binlog 最彻底，但若需主从或时间点恢复，必须设过期策略，且必须在 MySQL 内部生效，改宝塔界面或删文件都没用。
确认 binlog 是否开启及当前过期设置
先验证问题是否存在，避免白忙活：
- 执行
mysql -uroot -p -e "show variables like 'log_bin';"，返回ON表示已启用 - 执行
mysql -uroot -p -e "show variables like 'expire_logs_days';"，若结果是0或空，说明没设过期 - 执行
mysql -uroot -p -e "show binary logs;"看文件数量和大小，File_size列加起来超几个 GB 就得动手了
设置 expire_logs_days 并写入 my.cnf 永久生效
只运行 SET GLOBAL expire_logs_days = 7; 是临时的，MySQL 重启就失效。必须落盘才真正可靠：
- 编辑配置文件：
/www/server/mysql/etc/my.cnf（注意路径，不是/etc/my.cnf） - 在
[mysqld]段落末尾添加：expire_logs_days = 7（数字按需调整，建议 3–14） - MySQL 8.0.11+ 版本该参数已被标记为 deprecated，应改用：
binlog_expire_logs_seconds = 604800（7 天 = 604800 秒） - 保存后执行：
systemctl restart mysqld（或用宝塔面板重启 MySQL） - 重启后立刻验证：
mysql -uroot -p -e "show variables like 'expire_logs_days';"或对应新参数
PURGE BINARY LOGS 手动清理已有堆积
配置生效前已产生的大量 binlog 不会自动删，得手动触发一次 purge。不能用 rm，否则空间不释放、还可能中断复制：
- 登录 MySQL 后先查列表：
SHOW BINARY LOGS;记下最旧的文件名，比如mysql-bin.000056 - 安全做法是按文件名清理：
PURGE BINARY LOGS TO 'mysql-bin.000057';（保留 000057 及之后） - 也可按时间清理：
PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00';，注意格式必须是Y-m-d H:i:s - 执行后立即
df -h查磁盘，空间应实时释放——因为 MySQL 主动 unlink，内核回收 - 如果 MySQL 已无法启动（磁盘 100%），需先停服务 → 临时注释
my.cnf中的log-bin行 → 启动 → purge → 恢复log-bin→ 重启
在宝塔计划任务中加自动清理脚本（防配置遗漏）
仅靠配置文件有风险：某次升级覆盖、手误删行、或忘记重启服务，都会导致策略失效。加一层定时脚本更稳：
- 新建脚本：
/www/server/panel/script/clean_binlog.sh - 内容写成：
#!/bin/bash\nmysql -uroot -p$(cat /www/server/panel/database/default.pl) -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);" - 给执行权限：
chmod +x /www/server/panel/script/clean_binlog.sh - 在宝塔【计划任务】中添加：任务类型选“Shell 脚本”，周期设“每天 02:00”，脚本内容填
/www/server/panel/script/clean_binlog.sh - 注意：该脚本只是兜底，不能替代
my.cnf中的expire_logs_days配置，两者要并存
真正容易被忽略的是：expire_logs_days 的清理动作发生在 MySQL 每日轮转时，不是实时的；而 PURGE 命令才是即时释放空间的唯一可靠方式。配置写对了，不代表磁盘马上变空——旧文件得靠 purge 主动删，新文件才按策略自动滚掉。
