mysql日志配置怎么设置，mysql慢查询日志怎么开启

MySQL 日志配置的核心结论

合理配置 MySQL 日志体系，是保障数据安全、实现故障快速追溯、优化查询性能的基石。 生产环境必须同时开启错误日志、慢查询日志和二进制日志，并辅以科学的日志轮转与存储策略，只开启默认配置远远不够，针对业务特性进行精细化调优，才能让日志成为排障和优化的利器,而非拖垮磁盘的负担。

认识 MySQL 三大核心日志

MySQL 日志体系看似庞杂，但生产环境最常用、最核心的只有三类，理解它们的职责边界,是配置的第一步。

• 错误日志（Error Log）：记录启动、运行、停止过程中的关键事件，包括致命错误、警告、连接异常等。排查启动失败和突发故障时，错误日志是首要检查对象。
• 慢查询日志（Slow Query Log）：记录执行时间超过设定阈值的 SQL 语句，是定位性能瓶颈、优化索引和 SQL 写法的直接依据。
• 二进制日志（Binlog）：记录所有导致数据变更的操作（如 INSERT、UPDATE、DELETE），用于数据恢复、主从复制和时间点恢复,是数据库高可用架构的基石。

生产环境日志配置详解

错误日志配置

错误日志默认开启，但默认路径可能不够显眼，建议显式指定路径,并确保磁盘空间充足。

[mysqld]
log_error = /var/log/mysql/error.log
log_error_verbosity = 2

• log_error：定义日志文件路径。
• log_error_verbosity：取值 1 只记录错误，2 记录错误和警告，3 额外记录备注信息，生产环境建议设为

  

  2，既能捕获潜在威胁,又不被冗余信息淹没。

慢查询日志配置

慢查询日志是性能优化的核心工具,配置要点在于合理设定阈值和捕获范围。

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
log_queries_not_using_indexes = ON
min_examined_row_limit = 100

• long_query_time：阈值时间（秒）。建议从 2 秒起步，业务量大的系统可调整到 1 秒，若该值过小，日志量会激增；过大则失去优化意义。
• log_queries_not_using_indexes：记录所有未使用索引的查询，即使执行速度很快。这类 SQL 往往是潜在性能炸弹,在数据量增长后会急剧变慢。
• min_examined_row_limit：只记录扫描行数超过该值的查询,可过滤掉微小查询的噪音。

快照与实时分析技巧：慢查询日志会持续增长，建议每次排查时先用 mysqldumpslow 工具聚合统计：

mysqldumpslow -s at -t 10 /var/log/mysql/slow.log

该命令按平均耗时排序，展示最慢的 10 条语句，能快速锁定需要优化的 SQL。

二进制日志配置

二进制日志直接关系到数据安全和主从复制,必须谨慎规划。

[mysqld]
log_bin = /var/log/mysql/mysql-bin
server_id = 1
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 256M
sync_binlog = 1

• binlog_format = ROW：行级格式，记录每行数据的实际变更，

  

  比 STATEMENT 格式更安全,能避免存储函数等导致的主从数据不一致。

• expire_logs_days：自动清理 N 天前的 binlog。建议根据备份策略设定,至少要覆盖一次全量备份的周期。
• max_binlog_size：单个 binlog 文件体积上限,达到后自动滚动。
• sync_binlog = 1：每次事务提交前强制刷盘，在最坏情况下最多丢失一条事务，如果对性能极度敏感且能容忍少量丢失，可设为 0 或 100,但生产环境通常不建议。

日志存储与轮转策略

日志无限增长会拖垮磁盘，引发系统性风险，MySQL 没有内置的日志轮转能力,需要借助系统层工具。

• 使用 logrotate 统一管理：Linux 下通过 /etc/logrotate.d/mysql 配置每日切割、压缩和保留数量。
• 定期清理慢查询日志：慢日志不需要长期保留，一般保留 30 天即可，如需历史对比,可压缩归档到冷存储。

/var/log/mysql/slow.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
    create 640 mysql mysql
}

酷番云实战经验案例

我们在酷番云上帮助一家电商客户做过一次典型的日志调优，该客户此前只开启了错误日志，慢查询日志完全关闭，线上商品搜索接口平均响应 500ms，但每天有几十次超过 10 秒的超时请求。

排查过程：我们开启慢查询日志并设置 2 秒阈值，三天后收集到 2000+ 条慢 SQL，分析发现 80% 的慢查询集中在订单表关联查询，且 WHERE

条件中的 user_id 和 status 字段缺少联合索引。

解决方案：

• 为该表添加 (user_id, status) 联合索引，慢查询量下降 95%。
• 同时将 long_query_time 调整为 1 秒,持续监控新上线的业务模块。
• 利用酷番云云硬盘快照功能，将 binlog 过期时间设置为 7 天，并每日自动备份到对象存储，实现低成本、安全可靠的数据保护。

最终效果：搜索接口平均响应降到 120ms 以内，磁盘运维压力归零，还顺手解决了此前 binlog 占用空间过大的隐患。

相关问答模块

问题 1：MySQL 开启了慢查询日志后，性能会下降很多吗？

解答：不会有明显下降，慢查询日志写入采用异步方式，主要是记录语句和执行时间，对数据库整体吞吐影响很小，通常低于 5%，但要注意避免在性能压测时开启全量字段日志（如 log_output = TABLE 加 long_query_time = 0），那样会生成大量行，才可能拖累表现，正常生产环境按建议阈值开启,完全放心。

问题 2：binlog 过期时间设置多长才算合理？

解答：这取决于你的备份策略，核心原则是 binlog 保留时长 ≥ 最近一次全量备份的时间间隔，比如你每天凌晨 2 点做全量备份，binlog 至少保留 24 小时；若每周日做全量备份，则至少保留 7 天，这样无论任何时刻发生误操作，你都能用全量备份 + binlog 恢复到指定时间点，磁盘充裕时可多留几天，但不宜超过 15 天,以免恢复时处理过多日志。