PURGE BINARY LOGS是唯一安全的binlog清理方式，因其能同步更新mysql-bin.index、GTID集和从库位点，而手动删文件会破坏主从同步、导致启动报错或复制中断。
不能直接用 rm -f 删除任何 MySQL 日志文件，尤其是 mysql-bin.* —— 这会破坏主从同步、导致恢复失败，甚至让 MySQL 启动报错。
为什么 PURGE BINARY LOGS 是唯一安全的 binlog 清理方式
MySQL 的二进制日志不是普通文件，它和 mysql-bin.index、内存中的 GTID 集、从库复制位点强绑定。手动删文件后，SHOW BINARY LOGS 可能返回空，IO 线程卡住，RESET MASTER 会重置序列号，主从链路直接断裂。
-
PURGE BINARY LOGS TO 'mysql-bin.000123'：只删该文件之前的全部日志（不含它自己），最精准 -
PURGE BINARY LOGS BEFORE '2026-06-25 00:00:00'：注意时区，建议用NOW() - INTERVAL 7 DAY避免手误 - 执行前必须确认从库已同步：在从库查
SHOW SLAVE STATUS\G中的Relay_Master_Log_File，确保不删它 - 删完不可回滚，没有事务保障，操作前建议先
mysqldump备份关键库
error.log 和 slow_query_log_file 可以清空，但方法不同
这两类文本日志不参与复制或恢复，但清空方式有本质区别：
-
error.log：MySQL 持有文件句柄，不能rm，应使用truncate -s 0 /var/log/mysql/error.log（保持句柄不变，继续写入） -
slow_query_log_file：可先动态关闭日志SET GLOBAL slow_query_log = OFF，再rm对应文件，最后SET GLOBAL slow_query_log = ON重建 - 更稳妥的做法是接入
logrotate，配置copytruncate或create，避免服务中断
自动清理必须生效，不能只改配置就以为完事
binlog_expire_logs_seconds = 604800（7 天）在 MySQL 8.0.23+ 是推荐方式，但它不会“立刻清理”——清理触发依赖 FLUSH LOGS 或每日定时检查。很多实例因长期未重启或没执行过 FLUSH LOGS，导致配置形同虚设。
- 设完变量后，立即执行
FLUSH LOGS触发首次清理 - 生产环境建议加 crontab：
0 2 * * * mysql -e "FLUSH LOGS;"，每天凌晨强制刷新一次 - 检查是否真在清理：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';+SHOW BINARY LOGS;对比几天内的文件数量变化 - 别混用
expire_logs_days和binlog_expire_logs_seconds，后者优先级更高，前者设为 0 更安全
误删 mysql-bin.index 怎么快速恢复
这个文件丢失后，SHOW BINARY LOGS 返回空，PURGE 失效，主从 IO 线程停摆。但只要 MySQL 还在运行，就有救：
- 立刻执行
FLUSH BINARY LOGS：它会扫描当前存在的mysql-bin.000*文件并重建mysql-bin.index - 如果 MySQL 已崩溃，先确认
log_bin = ON（SELECT @@log_bin返回 1），再手动重建 index 文件：把所有现存mysql-bin.000*文件名按数字顺序写入/var/lib/mysql/mysql-bin.index，每行一个，路径必须绝对准确 - 切忌用
RESET MASTER补救——它会清空全部 binlog 并重置序列号，等同于主动断主从
真正容易被忽略的点是：清理不是一次性动作，而是持续策略。磁盘告警时的紧急 PURGE 只是止血，长期靠 binlog_expire_logs_seconds + FLUSH LOGS 定期触发 + logrotate 管理文本日志，三者缺一不可。任何环节漏掉，下次还会爆。
