MySQL 的 binlog 日志如何安全清理
直接
rm -f删除
binlog文件会破坏 MySQL 复制和恢复能力，必须通过 SQL 命令或配置自动过期控制。 查看当前 binlog 列表：
SHOW BINARY LOGS;删除指定日志前的所有 binlog（不含该文件）：
PURGE BINARY LOGS TO 'mysql-bin.000010';按时间清理：比如保留最近 7 天的 binlog：
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);执行前务必确认从库已同步完成（
SHOW SLAVE STATUS\G中
Relay_Master_Log_File≤ 要保留的 binlog 文件名）
设置 binlog 自动过期时间（expire_logs_days 已弃用）
MySQL 8.0.11+ 推荐使用
binlog_expire_logs_seconds替代旧参数，精度更高且支持秒级控制。
SET PERSIST binlog_expire_logs_seconds = 604800; -- 7 天，单位：秒 -- 永久生效需写入 my.cnf： # [mysqld] # binlog_expire_logs_seconds = 604800旧参数
expire_logs_days在 8.0.11+ 仍可读，但写入时会被忽略或转为等效的
binlog_expire_logs_seconds设置值为 0 表示不自动清理，此时必须手动
PURGE，否则磁盘可能被撑爆 该参数只影响 binlog，不影响
error log或
slow query log
错误日志（error log）轮转不靠 MySQL 内置机制
MySQL 本身不提供 error log 的自动轮转，依赖外部工具（如
logrotate）或手动触发
FLUSH ERROR LOGS。 手动轮转（生成新 error log，旧文件保留在原路径）：
FLUSH ERROR LOGS;Linux 下推荐用
logrotate配合
copytruncate，避免中断 MySQL 进程：
/var/log/mysql/error.log {
daily
missingok
rotate 30
compress
copytruncate
create 640 mysql mysql
}
copytruncate是关键：先拷贝再清空原文件，MySQL 不需要重启或重定向句柄 不要用
rename类方式直接移动 error log，MySQL 不会自动创建新文件 检查
my.cnf中
log_error路径是否与 logrotate 配置一致
慢查询日志（slow query log）轮转与清理要点
慢查询日志默认不轮转，开启后若长期不处理，单个文件极易达到 GB 级别。
启用并指定路径：SET GLOBAL slow_query_log = ON; SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';轮转方式同 error log：用
logrotate+
copytruncate，或先关闭再重命名再开启：
SET GLOBAL slow_query_log = OFF; -- mv /var/log/mysql/mysql-slow.log /var/log/mysql/mysql-slow.log.20240501 SET GLOBAL slow_query_log = ON;注意：MySQL 不会自动压缩或删除历史 slow log，全靠运维策略 如果启用了
log_output = TABLE（写入
mysql.slow_log表），则需定期
TRUNCATE TABLE mysql.slow_log;，而非文件操作
MySQL 日志管理最易被忽略的是 binlog 清理与主从同步状态的耦合——删早了从库追不上，删晚了磁盘爆掉。error log 和 slow log 轮转则常因依赖
FLUSH命令却未配合外部工具而失效。
