根本原因是binlog_expire_logs_seconds默认为0且expire_logs_days在8.0.11+已废弃，必须设非零秒数并开启auto_purge=ON，再查log_bin=ON、手动PURGE前核对从库Relay_Master_Log_File安全下限。
MySQL 配置了 log_bin 但磁盘写满，根本原因不是“日志太多”，而是自动清理压根没生效——binlog_expire_logs_seconds 默认为 0（永不清除），且 expire_logs_days 在 MySQL 8.0.11+ 已废弃，设了也白设。
确认 binlog 清理参数是否真在起作用
别信配置文件里写了就等于生效。先连进 MySQL 查实况：
-
SHOW VARIABLES LIKE 'log_bin';必须返回ON，否则 binlog 没开，谈不上清理 -
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';若是0或NULL，说明自动清理完全关闭 -
SHOW VARIABLES LIKE 'binlog_expire_logs_auto_purge';必须是ON，否则秒数再对也没用 -
SHOW BINARY LOGS;看最早那个文件的File_size和生成时间，比对是否已超你设的保留周期
MySQL 8.0+ 必须用 binlog_expire_logs_seconds 配置
expire_logs_days 在 8.0.11+ 中已被弃用，设了会触发错误 [3683]，且不生效。必须用秒级参数：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 7 天对应
604800秒，临时生效：SET GLOBAL binlog_expire_logs_seconds = 604800; - 永久生效：编辑配置文件（宝塔用户是
/www/server/mysql/etc/my.cnf），在[mysqld]段末尾加两行：binlog_expire_logs_seconds = 604800binlog_expire_logs_auto_purge = ON - 改完必须重启：
systemctl restart mysqld，否则变量不加载 - 顺手清掉旧残留：
SET GLOBAL expire_logs_days = 0;，避免干扰
PURGE BINARY LOGS 手动清理前必须核对从库状态
自动清理只管“未来”，已堆积的旧日志不会被自动删。磁盘告急时得手动干预，但误删一条就断主从：
- 主库执行：
SHOW MASTER STATUS;，记下当前File（如mysql-bin.000042） - 每台从库执行：
SHOW SLAVE STATUS\G，重点看Relay_Master_Log_File（如mysql-bin.000035） - 取所有从库中该字段序号最小的那个（比如
mysql-bin.000035），就是安全下限——最多只能PURGE TO 'mysql-bin.000036';（注意：不删 .000036 本身） - 如果是 GTID 模式（
gtid_mode = ON），禁止用TO，改用时间点：PURGE BINARY LOGS BEFORE '2026-10-28 00:00:00'; - 绝对不要用
RESET MASTER——它清空全部 binlog 并重置序列号，从库全中断
清理后空间没释放？大概率是文件句柄被占用
PURGE 是逻辑删除，Linux 下若 MySQL 进程仍在持有已删文件的句柄，df -h 就看不到空间释放：
- 验证命令：
lsof | grep deleted | grep mysql，若有输出，说明句柄还在 - 解决办法：执行
FLUSH BINARY LOGS;触发日志轮转，或直接重启mysqld - 注意：
binlog_expire_logs_seconds只对「非当前正在写的 binlog」生效，不会动mysql-bin.000xxx这种活跃日志；单个文件过大（靠max_binlog_size控制）会导致清理滞后，建议搭配使用
