如何为MySQL数据库启用慢查询日志功能？-mysql教程-PHP中文网

mysql 5.1+ 和 mariadb 5.2+ 支持慢查询日志，但需编译启用且不能动态开启；须通过 my.cnf 配置 slow_query_log=on、指定可写路径及 long_query_time，并重启验证；云数据库需用控制台下载，推荐 pt-query-digest 分析日志。

如何为mysql数据库启用慢查询日志功能？

确认 MySQL 是否支持慢查询日志

不是所有 MySQL 编译版本都默认启用 slow_query_log 功能，尤其是某些精简版或容器镜像（如 Alpine 基础镜像构建的 MySQL）。执行 SHOW VARIABLES LIKE 'slow_query_log%';，如果返回空或 slow_query_log 值为 OFF，说明未启用；若提示 Unknown system variable，则当前版本不支持（极少见，多见于 MariaDB 10.4 以下或极老 MySQL 5.0）。

常见错误现象：SET GLOBAL slow_query_log = ON; 报错 Variable 'slow_query_log' is a read only variable —— 这说明必须通过配置文件启动时加载，不能动态开启。

检查支持性：运行 SELECT VERSION();，MySQL 5.1+ 和 MariaDB 5.2+ 均支持，但需确认编译时启用了 --with-extra-charsets=all 等基础选项
生产环境建议先查 mysqld --verbose --help | grep "slow" 输出中是否含 slow-query-log 项
Docker 用户注意：官方 mysql:8.0 镜像默认关闭该功能，需挂载自定义 my.cnf

修改 my.cnf 启用并配置日志路径

直接改运行中的 MySQL 配置不可靠，必须编辑持久化配置文件（通常是 /etc/mysql/my.cnf、/etc/my.cnf 或 /usr/etc/my.cnf），在 [mysqld] 段落下添加：

slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2.0

slow_query_log_file 路径必须由 MySQL 进程用户（如 mysql）可写，且目录存在。常见坑是路径写成 /var/log/mysql-slow.log（缺 mysql 子目录）导致启动失败，错误日志里会报 File '/var/log/mysql-slow.log' not found (OS errno 13 - Permission denied)。

long_query_time 单位是秒，支持小数（如 0.5），但 MySQL 5.7+ 默认以微秒精度记录，值设太小（如 0.01）会导致日志暴增
若使用 Percona Server，还可加 log_queries_not_using_indexes = ON，但会显著增加 I/O，仅调试期开启
避免将日志和数据文件放在同一块磁盘，尤其机械盘，否则慢查询本身会拖慢正常查询

验证日志是否真正写入

重启 MySQL 后，别急着查日志文件是否存在——先确认 MySQL 进程是否读取了配置。执行 SELECT @@slow_query_log, @@slow_query_log_file, @@long_query_time;，输出值应与配置一致。然后手动触发一条慢查询：

MySQL

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

下载

SELECT SLEEP(3);

再检查日志文件：tail -f /var/log/mysql/mysql-slow.log，应看到类似：

# Time: 2024-04-10T09:23:45.123456Z
# User@Host: root[root] @ localhost []  Id:    12
# Query_time: 3.000212  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1
use test;
SELECT SLEEP(3);

如果没内容，优先排查：mysqld 启动时是否报 Can't open log file；SELECT 是否被 query cache 缓存（MySQL 8.0 已移除，但 5.7 可能跳过记录）；或客户端连接时加了 /*+ MAX_EXECUTION_TIME(1000) */ 这类 hint 干扰判断。

日志时间戳是 UTC，不是系统本地时区，跨时区团队要注意对齐
Rows_examined 值远大于 Rows_sent 是典型扫描全表信号，比单纯看 Query_time 更值得优化
某些云数据库（如阿里云 RDS）不开放 slow_query_log_file 路径，需用控制台「慢日志下载」功能，而非 SSH 查文件

用 pt-query-digest 分析日志效率更高

原生日志是纯文本，人工翻看低效。Percona Toolkit 的 pt-query-digest 是事实标准工具，它能把散乱日志聚合成统计报表：

pt-query-digest /var/log/mysql/mysql-slow.log --limit 10

输出会按响应时间、扫描行数、出现频次排序 Top SQL，并给出 EXPLAIN 建议。容易忽略的是：它默认只分析最近 1 天的日志，若日志轮转频繁（如 mysql-slow.log.1.gz），需显式指定多个文件或解压后合并处理。

不要在生产库上直接跑 pt-query-digest --processlist，它会持续抓取 SHOW PROCESSLIST，加重负载
若日志含敏感字段（如 SELECT password FROM users），加 --filter '$event->{Bytes} = 0' 清洗，或提前用 sed 脱敏
MySQL 8.0 开始支持 log_output = 'TABLE' 写入 mysql.slow_log 表，但该表是 CSV 引擎，查询性能差，不推荐替代文件日志

慢查询日志本身不加密、不压缩，长期开启要考虑磁盘空间增长和归档策略，特别是 long_query_time 设得过低时，日志体积可能超过预期数倍。