MySQL如何开启慢查询日志功能(5.7与8.0版本参数配置)

开启慢查询日志需在my.cnf中配置slow_query_log=1、指定slow_query_log_file路径并设置long_query_time阈值，重启mysql服务后生效；常见问题包括配置文件路径错误、权限不足、未重启服务、阈值过高或log_output设置不当；合理设置long_query_time应基于业务SLA和逐步调优，避免日志过大可通过logrotate轮转、定期分析pt-query-digest报告、优化SQL和索引来解决。

在MySQL中开启慢查询日志，核心就是修改配置文件

my.cnf

（或windows上的

my.ini

），设置

slow_query_log

为ON，指定日志文件路径

slow_query_log_file

，并定义一个查询耗时阈值

long_query_time

。无论MySQL 5.7还是8.0，这些参数的设置方式基本一致，区别主要在于一些默认值或次要功能上，但基础配置逻辑没变。

解决方案

要让MySQL开始记录那些执行缓慢的sql语句，我们需要直接编辑其配置文件。通常，这个文件在linux系统上可能位于

/etc/my.cnf

、

/etc/mysql/my.cnf

、

/usr/local/mysql/etc/my.cnf

，或者通过

mysql --help | grep "default options"

来查找。Windows系统则通常在MySQL安装目录下的

my.ini

。

找到配置文件后，在

[mysqld]

配置段下，加入或修改以下参数：

[mysqld] # 开启慢查询日志功能 slow_query_log = 1  # 指定慢查询日志文件的路径和名称 # 确保MySQL用户对这个路径有写入权限 slow_query_log_file = /var/log/mysql/mysql-slow.log  # 定义慢查询的时间阈值，单位是秒。 # 比如这里设置为1秒，意味着所有执行时间超过1秒的查询都会被记录。 # 可以是小数，比如0.1秒。 long_query_time = 1  # 如果你希望慢查询日志也记录不使用索引的查询，可以加上这个（MySQL 5.6.5+） # log_queries_not_using_indexes = 1  # 默认情况下日志输出到文件，但如果被修改过，确保是FILE # log_output = FILE

配置完成后，最关键的一步是重启MySQL服务，这样配置才能生效。在Linux上，通常是执行

sudo systemctl restart mysql

或

sudo service mysql restart

。

重启后，你可以执行一个故意慢的查询来测试，比如

select SLEEP(2);

，然后检查指定路径下的慢查询日志文件是否已生成并记录了这条查询。

为什么我的慢查询日志没有生效？

这问题我遇到过不止一次，尤其是在生产环境，发现日志没动静的时候，心里是真有点慌的。排查起来，通常有几个方向：

第一，配置文件路径不对。你可能改了一个

my.cnf

，但MySQL实际加载的是另一个。最稳妥的办法是登录MySQL，执行

SHOW VARIABLES LIKE 'datadir';

，然后通常配置文件就在数据目录的上一级或者

/etc

下。或者用

ps -ef | grep mysql

看看MySQL进程启动时有没有带

--defaults-file

参数。

第二，文件或目录权限问题。这是最常见的坑！你指定的

slow_query_log_file

路径，MySQL运行用户（比如

mysql

用户）必须有写入权限。如果日志文件所在的目录不存在，或者目录存在但

mysql

用户没有创建文件的权限，日志就写不进去。我一般会手动创建目录并赋予权限，比如

sudo mkdir -p /var/log/mysql && sudo chown -R mysql:mysql /var/log/mysql

。SELinux或AppArmor也可能阻拦，遇到这种情况，需要检查系统日志（

/var/log/audit/audit.log

或

dmesg

）并进行相应的配置调整。

第三，MySQL服务没有重启。修改了配置文件，但没有重启MySQL服务，配置是不会生效的。这就像你换了件衣服，但没出门，别人当然不知道你换了。

第四，

long_query_time

设置得太高。你可能设了个100秒，结果你的查询根本就没有那么慢的，自然日志里就啥也没有。或者，你正在测试的查询其实并没有达到你设定的阈值。

第五，

log_output

参数的问题。虽然默认是

FILE

，但如果你的系统之前被改过，比如设置成了

NONE

或者

table

，那么日志就不会写入文件。用

SHOW VARIABLES LIKE 'log_output';

检查一下。

最后，检查MySQL的错误日志（通常在数据目录下，以

.err

结尾的文件），如果慢查询日志启动失败，那里通常会有明确的错误提示，这往往是解决问题的金钥匙。

如何合理设置long_query_time参数？

设置

long_query_time

，这就像是给你的数据库性能划一条线。划得太低，日志会瞬间爆炸，磁盘I/O压力大，日志分析也变得困难，因为“慢查询”太多了，你不知道从何下手。划得太高，又可能漏掉那些虽然没那么慢，但累计起来却严重影响用户体验的“亚健康”查询。

我的经验是，没有一个放之四海而皆准的数字。这取决于你的业务特性、服务器配置以及对响应时间的要求。

1. 从业务SLA（服务等级协议）出发：如果你的业务要求页面加载时间在2秒内，那么你可能需要将

   long_query_time

   设置在0.5秒到1秒之间，这样你就能捕获到那些可能导致页面响应超时的数据库查询。

2. 逐步调整法：如果你是第一次开启慢查询，或者对系统性能不甚了解，可以先设置一个相对保守的值，比如

   long_query_time = 5

   秒。运行一段时间，分析日志，看看哪些查询是真正的瓶颈。然后，根据分析结果，逐渐降低这个值，比如降到2秒，再到1秒，甚至0.5秒。这个过程需要持续观察日志量和系统资源消耗。

3. 考虑查询频率：有些查询单次执行很快，但被高频调用，累计起来的资源消耗非常可观。慢查询日志主要针对单次执行耗时。对于高频但单次不慢的查询，需要结合其他监控工具（如

   pt-query-digest

   分析binlog或general log）来发现。

4. 特殊情况：

   • 开发/测试环境：可以设置得非常低，比如

     0.1

     秒甚至

     0

     秒（记录所有查询），以便彻底发现所有潜在问题。但生产环境绝对不要这么做。

   • 凌晨数据同步/etl：这些操作可能涉及大量数据处理，单次查询时间长是正常的。可以考虑在这些时段暂时调高

     long_query_time

     ，或者在分析时排除这些已知情况。

记住，

long_query_time

的目的是帮助你识别需要优化的查询，而不是为了制造一个巨大的日志文件。找到一个平衡点，既能捕获到有价值的信息，又不会给系统带来额外的负担，这才是最重要的。

慢查询日志文件过大怎么办？

慢查询日志文件随着时间的推移，确实会变得非常庞大，这不仅占用磁盘空间，也使得分析变得困难。管理好它们是日常运维的重要一环。

首先，日志轮转（Log Rotation）是必备的。在Linux系统上，

logrotate

工具就是为此而生。你可以配置

logrotate

，让它定期（比如每天或每周）将当前的慢查询日志文件重命名、压缩，并创建新的日志文件。同时，

logrotate

还能管理旧日志的保留策略，比如只保留最近7天的日志。配置通常在

/etc/logrotate.d/mysql

或类似的路径下。这样，即使日志文件很大，也只是历史文件，不会持续增长。

其次，定期分析和清理。日志存在的价值在于分析。使用

pt-query-digest

这样的工具，可以非常高效地解析慢查询日志，生成一份可读性很高的报告，告诉你哪些查询是最慢的、执行次数最多的、扫描行数最多的等等。分析完并采取优化措施后，那些已经处理过的日志，就可以考虑归档或删除了。我通常会有一个脚本，在

logrotate

之后，对刚轮转出来的日志进行分析，然后根据分析结果决定是否压缩或删除。

再者，从根本上减少慢查询。这是治本的方法。如果你的慢查询日志总是很快就变得巨大，那说明你的数据库里有很多需要优化的查询。这可能涉及到：

• 索引优化：检查查询是否充分利用了索引，或者是否需要创建新的索引。
• SQL语句重写：优化

  JOIN

  操作、避免全表扫描、减少子查询等。

• 数据库结构优化：比如反范式设计以减少复杂联结，或者分区表。
• 硬件升级：如果优化到极致依然慢，那可能是硬件瓶颈，比如I/O、CPU或内存不足。

最后，如果是在一个非常繁忙的系统上，并且你发现慢查询日志的生成本身就对性能有一定影响（尽管通常很小），你可以在分析高峰期过后，或者在已知没有重要慢查询需要捕获的维护时段，暂时通过

SET GLOBAL slow_query_log = OFF;

来关闭日志，以减少写入开销。但请记住，这只是权宜之计，不是长久之策，并且在生产环境要慎用。