MySQL binlog必须用PURGE命令或binlog_expire_logs_seconds配置清理，严禁rm删除；error log和slow log需用logrotate+copytruncate或FLUSH命令轮转，且须确保主从同步完成后再清理binlog。
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 命令却未配合外部工具而失效。
