MySQL如何开启慢查询日志功能(5.7与8.0版本参数配置)-mysql教程-PHP中文网

开启慢查询日志需在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如何开启慢查询日志功能(5.7与8.0版本参数配置)

在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压力大，日志分析也变得困难，因为“慢查询”太多了，你不知道从何下手。划得太高，又可能漏掉那些虽然没那么慢，但累计起来却严重影响用户体验的“亚健康”查询。

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

从业务SLA（服务等级协议）出发：如果你的业务要求页面加载时间在2秒内，那么你可能需要将
long_query_time
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
设置在0.5秒到1秒之间，这样你就能捕获到那些可能导致页面响应超时的数据库查询。
逐步调整法：如果你是第一次开启慢查询，或者对系统性能不甚了解，可以先设置一个相对保守的值，比如
```
long_query_time = 5
```
登录后复制
秒。运行一段时间，分析日志，看看哪些查询是真正的瓶颈。然后，根据分析结果，逐渐降低这个值，比如降到2秒，再到1秒，甚至0.5秒。这个过程需要持续观察日志量和系统资源消耗。
考虑查询频率：有些查询单次执行很快，但被高频调用，累计起来的资源消耗非常可观。慢查询日志主要针对单次执行耗时。对于高频但单次不慢的查询，需要结合其他监控工具（如
```
pt-query-digest
```
登录后复制
登录后复制
分析binlog或general log）来发现。
特殊情况：
- 开发/测试环境：可以设置得非常低，比如
```
0.1
```
  登录后复制
  秒甚至
```
0
```
  登录后复制
  秒（记录所有查询），以便彻底发现所有潜在问题。但生产环境绝对不要这么做。
- 凌晨数据同步/ETL：这些操作可能涉及大量数据处理，单次查询时间长是正常的。可以考虑在这些时段暂时调高
  long_query_time
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  ，或者在分析时排除这些已知情况。