日志文件过大应先定位类型再清理：mysql五类日志（binlog、error log、general_log、slow_query_log、relay log）清理策略各异，须按类型分别处理，严禁误删导致主从断裂或日志写入失败。
日志文件太大，优先别删，先查清是哪类日志在撑爆磁盘。 MySQL 有五类主要日志（binlog、error log、general_log、slow_query_log、relay log），每类清理逻辑完全不同——误删 binlog 可能断主从，直接 rm error log 而不通知 MySQL 会导致新日志写不进磁盘，关 general_log 不用重启但关 binlog 必须重启且会丢 PITR 能力。
确认日志类型和占用来源
别猜，用命令定位真实大户：
- 查 binlog 总大小：
SHOW BINARY LOGS;看文件名和 Size，再用du -sh /var/lib/mysql/mysql-bin.*核对磁盘实际占用 - 查 error log 路径和大小：
SELECT @@global.log_error;，然后ls -lh $(mysql -Nse "SELECT @@global.log_error") - 确认 general_log 和 slow_query_log 是否开启：
SELECT @@global.general_log, @@global.slow_query_log;，若为 ON，立刻查SELECT @@global.general_log_file, @@global.slow_query_log_file; - 主从环境下必须先看从库进度：
SHOW SLAVE STATUS\G，重点核对Relay_Master_Log_File和Exec_Master_Log_Pos，确保你要删的 binlog 还没被从库读完
按日志类型分策略清理
不同日志，清理方式天差地别：
-
binlog：必须兼顾主从安全。MySQL 8.0+ 推荐配
binlog_expire_logs_seconds = 604800（7 天），5.7 用expire_logs_days = 7；手动清理只用PURGE BINARY LOGS BEFORE '2026-01-21 00:00:00'或PURGE BINARY LOGS TO 'mysql-bin.000150'，严禁用RESET MASTER（清空全部，主从必崩） -
error log：不建议直接
rm。正确做法是mv /var/log/mysql/error.log /var/log/mysql/error.log.20260128+kill -SIGUSR1 $(pgrep mysqld)（触发 MySQL 重开新文件），或配置logrotate自动轮转 -
general_log / slow_query_log：无内置自动清理机制。若必须保留，用
SET GLOBAL general_log = OFF;关闭后，再删文件；长期开启务必配logrotate，否则单日志文件可能超 10GB 导致 I/O 卡死
防复发：自动化与监控兜底
人工清理迟早漏掉，得靠机制：
- 加 cron 定时任务（如每天 2:00）：
mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY)"，但前提是已确认从库同步延迟 - 监控磁盘水位联动清理：当
df /var/lib/mysql | awk 'NR==2 {print $5}' | sed 's/%//'> 85 时，自动触发 binlog 清理脚本（注意加锁防并发） - 调低日志“噪音”：设
log_error_verbosity = 2（只记 ERROR/WARNING），关log_queries_not_using_indexes（除非正在专项优化索引），避免慢日志爆炸式增长
最容易被忽略的一点：PURGE BINARY LOGS 只删文件，不释放文件系统 inode；如果大量小 binlog 文件占满 inodes（df -i 查），即使磁盘空间充足也会报 “No space left on device”。此时需配合 find /var/lib/mysql -name "mysql-bin.[0-9]*" -mtime +7 -delete 彻底清理，但务必先停写、确认从库状态、备份 index 文件。
