mysql日志过大将迅速占满磁盘导致服务中断，需从应急处理、长期控制和配置优化三方面解决：紧急时用purge命令清理binlog、truncate清空error.log；长期配置expire_logs_days或binlog_expire_logs_seconds自动清理；日常关闭general_log、合理设置slow_query_log并接入logrotate。
MySQL日志文件过大，最直接的影响是磁盘空间被快速占满，严重时会导致数据库无法写入、服务中断。问题核心不在“能不能删”，而在于“怎么安全删、怎么不再涨”。下面从应急处理、长期控制和配置优化三个层面给出实用方案。
紧急释放磁盘空间
当磁盘已满或告警触发，需立即腾出空间：
- 先确认哪些日志在占用空间：用 find /var/lib/mysql -xdev -size +500M -exec ls -lh {} \; 快速定位大日志文件（如 mysql-bin.000xxx、slow-query.log、error.log）
- 二进制日志（binlog）不建议直接 rm 删除，应进入 MySQL 执行：
PURGE BINARY LOGS BEFORE '2025-12-15 00:00:00'; 或 PURGE BINARY LOGS TO 'mysql-bin.000123';（注意：不能 purge 正在使用的那个文件，可用 SHOW MASTER STATUS; 查看） - 错误日志（error.log）可直接清空：sudo truncate -s 0 /var/log/mysql/error.log（不删除文件句柄，不影响 MySQL 继续写入）
- 慢查询日志和通用查询日志若非必要调试中，可停用后删除：
SET GLOBAL slow_query_log = OFF;，再手动删 slow_query_log_file 对应的文件
避免反复爆满：配置自动清理
靠人工清理治标不治本，关键要让 MySQL 自己定期归档或丢弃旧日志：
- 编辑 /etc/my.cnf 的 [mysqld] 段，添加或修改：
- expire_logs_days = 7（MySQL 5.7 及以前）
- binlog_expire_logs_seconds = 604800（MySQL 8.0+，推荐，精度更高）
- 同时建议设 max_binlog_size = 100M，防单个 binlog 文件过大
- 修改后重启服务：systemctl restart mysqld（或使用对应命令）
- 验证是否生效：SHOW VARIABLES LIKE '%expire%';
规范日志使用习惯
很多日志膨胀源于“开着不用、用了不管”：
- 关闭不必要的日志：除非审计或调试需要，禁用 general_log（通用查询日志）——它记录每条 SQL，增长极快；SET GLOBAL general_log = OFF; 并注释掉 my.cnf 中的 general_log=1
- 慢查询日志只在性能排查期开启，日常建议关掉，或调高阈值（如 long_query_time = 5）
- 主从环境中，务必确认从库已同步完毕再清理 binlog；可用 SHOW SLAVE STATUS\G 查看 Relay_Master_Log_File 和 Exec_Master_Log_Pos，确保不早于待 purge 的位置
- 对 error.log、slow.log 等文本日志，建议接入 logrotate 管理，按天轮转、压缩、保留7份，避免堆积
日志不是越全越好，而是够用、可控、可追溯。合理配置 + 定期检查，基本就能把日志体积稳在合理范围。
