mysql 8.0+ 必须使用 binlog_expire_logs_seconds（如604800秒=7天），expire_logs_days已废弃且无效；需设为0避免冲突，并配合flush logs触发清理。
必须用 binlog_expire_logs_seconds（MySQL 8.0+）
MySQL 8.0 开始，expire_logs_days 已被标记为 deprecated，设了也不保证生效——尤其在 8.0.23+ 版本里直接失效。你看到 SHOW VARIABLES LIKE 'expire_logs_days' 返回非零值，不代表它在管事。
正确做法只有一条：SET GLOBAL binlog_expire_logs_seconds = 604800;（7 天），并立刻写入配置文件。否则重启就回退，磁盘迟早爆。
注意两个坑：
-
binlog_expire_logs_seconds和expire_logs_days同时存在会冲突，清理可能完全不触发。务必先执行SET GLOBAL expire_logs_days = 0; - 该参数只影响「后续新生成的 binlog」，已存在的旧文件不会立刻删——MySQL 在下次 binlog 切换或每小时检查时才清理
PURGE BINARY LOGS 手动清理前必须核对从库状态
手动删比自动删快，但错一次就断主从。不能只看时间或文件名，得确认所有从库都“追平”了你想删的边界。
安全三步：
- 主库执行
SHOW MASTER STATUS;，记下当前File（比如mysql-bin.000150） - 每台从库连上去跑
SHOW SLAVE STATUS\G，盯住Relay_Master_Log_File和Exec_Master_Log_Pos - 找出所有从库中
Relay_Master_Log_File最旧的那个（比如mysql-bin.000132），这就是你能PURGE TO的底线：执行PURGE BINARY LOGS TO 'mysql-bin.000133';
别用 BEFORE 配当前时间减 7 天——binlog 关闭时间 ≠ 系统时间，且时区容易错，TO 更可控。
FLUSH LOGS 是磁盘已满时最安全的触发动作
磁盘使用率超 95% 时，INSERT 可能卡在 Writing to net 或 Copying to tmp table，这不是网络慢，是写不进磁盘了。此时 RESET MASTER 绝对禁用——它会清空全部 binlog 并重置序列号，从库立刻同步失败。
正确应急操作只有：FLUSH LOGS;
- 它会强制切换出一个新 binlog 文件（如
mysql-bin.000151） - 同时触发内部清理逻辑，把已过期、且无从库依赖的旧文件真正删掉
- 不改位点、不中断复制、不重置序列，风险最低
如果 FLUSH LOGS 卡住，说明磁盘真的没空间了——先删 error.log 或 slow-query.log（用 truncate -s 0，别 rm），腾出几百 MB 再试。
宝塔/脚本自动化清理要绕过密码明文风险
很多定时脚本直接用 mysql -uroot -p$(cat /www/server/panel/database/default.pl)，但 default.pl 权限若不是 600，其他用户可读 root 密码。
更稳妥的做法：
- 建专用账号：
CREATE USER 'cleaner'@'localhost' IDENTIFIED BY 'xxx'; GRANT REPLICATION CLIENT, SUPER ON *.* TO 'cleaner'@'localhost'; - 用配置文件传参：
mysql --defaults-extra-file=/etc/mysql/purge.cnf -e "PURGE BINARY LOGS BEFORE '$(date -d '7 days ago' '+%Y-%m-%d %H:%M:%S')"; -
/etc/mysql/purge.cnf内容仅两行：[client]user=cleanerpassword=xxx，权限必须chmod 600 /etc/mysql/purge.cnf
自动清理不是配完就完事——得配监控，比如每天检查 SHOW BINARY LOGS; 返回的文件数是否持续增长，或者 df -h 看 /var/lib/mysql 使用率是否逼近 90%。
