如何在MySQL 8.0中正确开启并配置慢查询日志阈值-mysql教程-PHP中文网

mysql 8.0慢查询日志必须修改my.cnf并重启生效，set global仅临时开启且不持久；确认启用需执行show variables like 'slow_query_log'返回on，否则未生效；关键配置包括slow_query_log = on、long_query_time = 1.0、slow_query_log_file = /var/log/mysql/slow.log及log_output = file，并验证select sleep(2)是否写入日志。

如何在mysql 8.0中正确开启并配置慢查询日志阈值

MySQL 8.0 的慢查询日志必须通过配置文件修改并重启生效，SET GLOBAL 只能临时开启但不持久，且对已存在的连接无效。

确认 slow_query_log 是否真正启用

别信配置文件里写了就等于开了。连上 MySQL 后直接执行：SHOW VARIABLES LIKE 'slow_query_log';，返回值必须是 ON 才算启用。如果返回 OFF，说明配置没生效或被覆盖——常见原因是改错了配置文件（比如改了 /etc/my.cnf，但 mysqld 实际加载的是 /etc/mysql/my.cnf），可用 mysqld --help --verbose | grep "Default options" 查它到底读哪个文件。

顺手再查两个关键变量：SHOW VARIABLES LIKE 'slow_query_log_file'; 看日志写到哪（不是默认路径！）；SHOW VARIABLES LIKE 'long_query_time'; 看当前阈值（MySQL 8.0 默认仍是 10.0，不是业务能接受的值）。

my.cnf 必须写的三行配置

在 [mysqld] 段下只写这三行，多余参数反而干扰判断：

slow_query_log = ON —— 必须大写 ON，1、true、on 都会静默失败甚至导致启动报错
long_query_time = 1.0 —— 单位秒，支持小数；注意：该值对已有连接不生效，只影响新连接
slow_query_log_file = /var/log/mysql/slow.log —— 路径需绝对路径，父目录必须存在，且属主为 mysql 用户；用 sudo -u mysql touch /var/log/mysql/slow.log 测试是否可写

额外但强烈建议加一行：log_output = FILE。因为如果之前运行过 SET GLOBAL log_output = 'TABLE'，重启后即使 slow_query_log = ON，日志也不会写入文件——MySQL 不报错，但日志静默丢失。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

验证配置是否真起作用

重启服务后别等业务流量，立刻用 SELECT SLEEP(2); 触发一条明确超时的语句，然后马上检查日志文件：tail -n 5 /var/log/mysql/slow.log。能看到类似这样的内容才算成功：

# Time: 2026-10-13T18:22:33.456789Z
# User@Host: root[root] @ localhost []  Id: 123
# Query_time: 2.000123  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 1
use test;
SELECT SLEEP(2);

常见失败原因包括：

SELinux 或 AppArmor 拦截写入，用 ausearch -m avc -ts recent | grep mysqld 查拒绝记录
slow_query_log_file 路径的父目录权限不对，MySQL 启动时不报错但日志根本不会生成
log_output 被设成 TABLE 或 NONE，导致日志无处可落
应用使用长连接池，旧连接仍按默认 10.0 判断，需重连或手动执行 SET SESSION long_query_time = 1.0

DML 语句（INSERT/UPDATE/DELETE）默认不进慢日志

这是 MySQL 默认行为，不是配置错误。即使 INSERT INTO ... SELECT 执行了 5 秒，也不会出现在慢日志里。如果你真需要记录 DML，得额外开启 log_slow_admin_statements = ON（注意：它只影响部分管理类语句，不覆盖所有 DML）；更稳妥的做法是结合 Performance Schema 的 events_statements_history_long 表做实时抓取——但这属于另一套监控体系，和慢日志本身无关。

真正容易被忽略的点是：long_query_time 只计算语句纯执行耗时，不包含锁等待时间；而线上最卡的往往就是锁住等了几秒才执行完的 SQL——这类语句可能根本达不到阈值，却拖垮整个系统。所以光看慢日志远远不够，得配合 information_schema.INNODB_TRX 和 sys.innodb_lock_waits 一起分析。