直接查询 @@slow_query_log 变量值是最可靠方式，若为 0 则日志未启用，即使配置文件设置了 slow_query_log = ON 也可能因权限或路径问题静默失败。
如何确认 MySQL 慢查询日志当前是否启用
直接查 slow_query_log 变量值是最可靠的方式，而不是依赖配置文件是否存在相关项。执行：
SELECT @@slow_query_log, @@slow_query_log_file, @@long_query_time;如果返回
@@slow_query_log 为 0，说明日志实际未开启，哪怕 my.cnf 里写了 slow_query_log = ON 也没用——MySQL 启动时可能因权限、路径不可写等原因静默失败。
-
slow_query_log_file默认路径常为/var/lib/mysql/hostname-slow.log，但若目录不存在或 MySQL 用户无写权限，日志会创建失败且不报错 -
long_query_time默认是10.0秒，对 Web 应用来说完全没意义，建议调成0.5或1.0（支持小数） - 动态开启可执行
SET GLOBAL slow_query_log = ON;，但重启后失效；持久化必须写进配置文件并重启 mysqld
my.cnf 中必须写的三行配置（含路径与权限避坑）
只加 slow_query_log = ON 是不够的。以下三项需同时存在，且顺序无关，但路径必须显式指定：
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:mysql（不是root），否则 MySQL 启动时跳过日志初始化 - 不要用
~或环境变量，MySQL 不解析 shell 路径缩写 - 如果用 Docker，宿主机挂载的目录需提前
chown 999:999 /host/path（MySQL 官方镜像默认 uid=999）
如何验证慢查询日志真正在记录（绕过“以为开了其实没写”的陷阱）
别只看文件是否存在，要确认内容实时更新。最稳妥方法是手动触发一条慢查询：
SELECT SLEEP(2);
然后立刻检查日志文件末尾：
tail -n 5 /var/log/mysql/mysql-slow.log正常应看到类似：
# Time: 2024-06-15T10:22:33.123456Z<br># User@Host: root[root] @ localhost [] Id: 7<br># Query_time: 2.000123 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1<br>use test;<br>SELECT SLEEP(2);
- 如果没输出，先
ls -l /var/log/mysql/mysql-slow.log看文件大小和时间戳是否更新 - 注意 MySQL 8.0+ 默认启用
log_output = TABLE，此时日志写入mysql.slow_log表而非文件，需改用log_output = FILE -
general_log和slow_query_log是独立开关，别混淆
生产环境开启后必须做的两件事（否则等于白开）
日志文件不会自动轮转，不干预会导致磁盘打满；且默认不记录未使用索引的查询，漏掉大量潜在问题：
- 启用
log_queries_not_using_indexes = ON—— 这个开关必须显式打开，否则long_query_time再小也捕获不到全表扫描 - 用
mysqldumpslow或pt-query-digest分析日志，纯文本 grep 效率极低；mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log可快速找出耗时 Top 10 查询
路径权限、log_output 模式、未索引查询开关——这三个点漏掉任何一个，慢日志就只是个摆设。
