直接查系统变量show variables like 'slow_query_log'返回on才确认开启；同时检查slow_query_log_file路径权限和long_query_time阈值，动态设置需super权限且重启失效，持久化须配my.cnf并确保目录属主为mysql。
如何确认慢查询日志当前是否启用
直接查系统变量最可靠：SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 才算开启；OFF 就得手动开。别只看配置文件有没有写，MySQL 启动时可能因权限、路径不可写等原因静默失败，实际没生效。
顺手一起查两个关键参数：slow_query_log_file 看日志写到哪（默认在 datadir 下，如 /var/lib/mysql/localhost-slow.log），long_query_time 看当前阈值（单位秒，支持小数，比如 0.5 表示 500ms）。
运行时动态开启慢查询日志（无需重启）
只要 MySQL 有 SUPER 权限，就能用 SQL 实时开关：
SET GLOBAL slow_query_log = ON;
注意三点：
-
SET GLOBAL只影响新连接，已存在的连接不会自动继承新设置 - 如果
slow_query_log_file指向的目录 MySQL 进程没写入权限，开启后日志仍会静默失效——查mysqld错误日志里有没有Could not use ... for logging这类报错 - 该设置在 MySQL 重启后丢失，必须写进配置文件才能持久化
永久生效：修改 my.cnf 并注意路径与权限
在 [mysqld] 段落下加这三行（路径按实际调整）：
slow_query_log = ON<br>slow_query_log_file = /var/log/mysql/mysql-slow.log<br>long_query_time = 1.0
重点不是“加了就完事”，而是：
- 确保
/var/log/mysql/目录存在，且属主是mysql用户（chown mysql:mysql /var/log/mysql） -
long_query_time在 MySQL 5.7 中对包含锁等待的语句也生效，但阈值判断基于**执行完成总耗时**，不是纯 CPU 时间 - 如果启用了
log_queries_not_using_indexes，大量无索引的简单查询也会进慢日志，容易撑爆磁盘，不建议生产环境长期开启
验证日志是否真在记录（别信配置，要眼见为实）
人工触发一条明确超时的查询最直接：
SELECT SLEEP(2);
然后立刻去日志文件尾部看有没有新增记录：
tail -n 5 /var/log/mysql/mysql-slow.log
正常会看到类似：
# Time: 2024-04-10T10:20:30.123456Z<br># User@Host: root[root] @ localhost [] Id: 3<br># Query_time: 2.000234 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1<br>use test;<br>SELECT SLEEP(2);
如果没出现，优先检查 slow_query_log_file 路径权限、MySQL 错误日志、以及当前连接是否用了旧的 long_query_time 值（执行 SELECT @@long_query_time; 确认）。
阈值设太低（比如 0.1）会导致日志暴增，设太高又漏掉真实瓶颈；建议先从 1.0 开始，结合业务响应时间和 pt-query-digest 分析结果逐步下调。
