MySQL日志占满磁盘？三步轻松清理，让数据库“呼吸顺畅”！

MySQL作为数据库界的“劳模”，每天都会写“日记”——也就是各种日志，记录自己的操作、错误和慢动作。但日子久了，这些“日记”堆成山，磁盘空间就告急：告警邮件狂轰滥炸，数据库响应变慢，甚至直接罢工！别急，今天教你三步清理日志，让数据库重新“轻装上阵”～

第一步：先搞懂MySQL的“日志家族”有哪些？

MySQL的日志可不是“一刀切”，不同日志有不同作用，清理方法也不一样。先认清楚你要清理的是哪一位“成员”：

• 二进制日志（binlog）：数据库的“黑匣子”，记录所有修改数据的操作（增删改），用于恢复和主从复制。
• 错误日志（error log）：数据库的“病历本”，记录启动、运行中的错误信息，帮助排查问题。
• 慢查询日志（slow query log）：数据库的“错题本”，记录执行时间超过阈值的SQL，方便优化性能。
• 通用查询日志（general log）：数据库的“全程录像”，记录所有执行过的SQL，一般生产环境不开启。

第二步：清理前的“安全 Checklist”——别踩坑！

清理日志就像“整理房间”，得先做好准备，避免弄丢重要东西：

• 1. 确认日志是否还在“工作”：比如二进制日志如果是主从复制的“桥梁”，得确保从库已经同步了所有日志，再动手清理。
• 2. 备份重要日志：把需要保留的日志复制到其他磁盘（比如用cp error.log error.log.bak），万一后续需要排查问题还有迹可循。
• 3. 检查磁盘空间：用df -h看看日志占了多少空间，做到“心中有数”。

第三步：不同日志的“清理姿势”——对症下药！

针对不同日志，用对方法才能高效清理，还不伤害数据库：

• 二进制日志（binlog）：用命令“优雅删除”
  别直接rm！用MySQL自带的PURGE命令：
  比如删除2026年1月1日之前的日志：PURGE BINARY LOGS BEFORE '2026-01-01 00:00:00';
  或者设置自动过期：在my.cnf里加expire_logs_days=7（自动删除7天前的日志），重启生效。
• 错误日志/慢查询日志：清空或轮换
  如果日志文件太大，可以直接清空内容（不用删除文件，避免重启）：
  比如清空错误日志：truncate -s 0 /var/log/mysql/error.log
  或者删除旧日志，然后重启MySQL服务（生产环境尽量用truncate减少影响）。
• 通用查询日志：关闭+清理
  如果开启了通用查询日志且不需要，先在my.cnf里关闭（general_log=OFF），再清理日志文件即可。

第四步：长期“维稳”——让日志自动“瘦身”！

清理一次不够，得让日志“自律”起来：

• 设置自动过期：二进制日志用expire_logs_days，其他日志用系统工具logrotate定期轮换压缩。
• 关闭无用日志：生产环境关闭通用查询日志，慢查询日志只在需要优化时开启。
• 定期检查：每周用du -sh /var/log/mysql/看看日志大小，防患于未然。

最后提醒：清理日志时一定要小心，尤其是生产环境！如果不确定操作是否安全，先咨询DBA或者查MySQL