MySQL日志过多会拖慢性能，需合理配置与定期治理：设置binlog自动过期、精简error log级别、谨慎启用general_log和slow_query_log，并建立监控与自动化清理机制。
MySQL日志过多确实会拖慢性能，主要体现在磁盘I/O压力增大、写入延迟升高、备份与清理变慢，甚至可能触发磁盘空间告警。关键不是“关日志”，而是合理配置+定期治理。
控制二进制日志（binlog）体积
binlog是主从同步和时间点恢复的基础，但长期不清理会快速膨胀：
- 设置自动过期：在 my.cnf 中添加 expire_logs_days = 7（保留7天），MySQL 8.0+ 更推荐用 binlog_expire_logs_seconds = 604800
- 手动清理前先确认从库已同步：执行 SHOW SLAVE STATUS/G 查看 Relay_Master_Log_File 和 Exec_Master_Log_Pos，再用 PURGE BINARY LOGS TO ‘mysql-bin.000123′ 或 PURGE BINARY LOGS BEFORE ‘2025-12-09 00:00:00′
- 避免频繁开关 binlog：log_bin = OFF 会导致无法做主从和 PITR，仅限测试环境临时使用
精简错误日志（error log）输出
默认 error log 会记录 warning 级别以上信息，高频警告（如连接拒绝、表不存在）会让日志迅速变大：
- 调整日志级别：在 my.cnf 中设 log_error_verbosity = 2（只记 ERROR 和 WARNING；设为 1 则仅 ERROR）
- 关闭冗余记录：禁用 log_warnings = 0（MySQL 5.7 及以前有效；8.0+ 已由 log_error_verbosity 替代）
- 配合 logrotate：用系统级 logrotate 按大小或时间轮转，例如每周压缩归档 + 保留 4 周，防止单个文件超 500MB
谨慎启用通用查询日志与慢查询日志
这两类日志对性能影响显著，生产环境通常不建议长期开启：
- 通用查询日志（general_log）：记录所有 SQL，I/O 开销极大。仅调试时临时打开：SET GLOBAL general_log = ON;，排查完立即关掉
- 慢查询日志（slow_query_log）：建议开启，但要调严阈值：long_query_time = 1.0（而非默认 10 秒），并确保 log_queries_not_using_indexes = OFF（除非专项优化索引）
- 日志输出方式优选文件而非表（即 log_output = FILE），避免写入 mysql.slow_log 表带来的额外锁和事务开销
监控与自动化清理机制
靠人工定期清理不可靠，应建立轻量级运维闭环：
- 加监控项：检查 SHOW BINARY LOGS 总大小、error log 文件磁盘占用、slow log 最新修改时间
- 写简单脚本每日执行：比如用 shell 检查 /var/lib/mysql/*.err 大于 200MB 就 logrotate，或调用 mysql -e “PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY)”
- MySQL 8.0+ 可结合 Performance Schema 查看日志写入等待事件（如 wait/io/file/sql/binlog），辅助判断是否 I/O 成瓶颈