直接执行 SELECT @@slow_query_log; 查看慢查询日志是否启用，返回1表示已启用，0表示关闭；SHOW VARIABLES LIKE 'slow_query_log%'; 可同时查看启用状态、日志路径和阈值。
怎么确认慢查询日志当前是否开启
直接查 slow_query_log 变量值，别猜配置文件有没有生效：
- 连上 MySQL 后执行
SELECT @@slow_query_log;，返回1表示已启用，0表示关闭 - 即使
my.cnf里写了slow_query_log = ON，没重启或没用SET GLOBAL slow_query_log = ON;也不会生效 -
SHOW VARIABLES LIKE 'slow_query_log%';能一次性看到日志路径、阈值、是否启用三个关键项
设置 long_query_time 到多少才合理
别盲目设成 1 或 0.1 —— 这个值必须结合你的业务响应预期和数据库负载来看：
- 线上 OLTP 服务，建议从
0.5（500ms）起步；若平均查询都在 100ms 内，设成0.2更敏感 -
long_query_time是浮点数，支持小数，但注意：MySQL 5.7+ 默认单位是秒，不是毫秒 - 设太低（比如
0.01）会导致日志暴增，IO 压力大，甚至拖慢慢查询本身（日志写入会串行化部分操作） - 该变量可动态改：
SET GLOBAL long_query_time = 0.3;，但新连接才会继承这个值，已有连接仍用旧值
慢查询日志文件位置和权限问题
日志写不进去？大概率是路径或权限卡住了，而不是配置没写对：
- 默认路径通常是
/var/lib/mysql/hostname-slow.log，但实际以slow_query_log_file变量值为准 - MySQL 进程用户（如
mysql）必须对目录有写权限，且不能写到 root 用户专属路径（比如/root/） - 如果启用了
log_output = FILE（默认），但日志文件被手动删过，MySQL 不会自动重建，得重启 mysqld 或用FLUSH LOGS; - 用
mysqld --verbose --help | grep "slow"可看到编译默认的 slow log 路径，方便排查配置冲突
用 mysqldumpslow 快速筛出高频慢查询
别直接 tail -f 慢日志文件——内容杂、重复多、看不出模式：
-
mysqldumpslow -s c -t 10 /var/lib/mysql/slow.log按出现次数排序，取前 10 条，能立刻定位“哪个 SQL 被反复拖慢” -
-s at是按平均耗时排，-s al是按锁等待时间排，不同场景换参数 - 注意：该工具会自动合并带不同参数的相同 SQL（比如
WHERE id = 1和WHERE id = 2算同一条），所以结果里的N是调用次数，不是日志行数 - 如果日志里大量出现
# Time: 2024...但没后续 SQL，说明查询被截断了，可能是max_allowed_packet太小或日志格式异常
慢查询日志本身不记录执行计划，只记 SQL 文本和耗时。想定位瓶颈，得拿 top 出来的 SQL 去 explain，再结合 SHOW PROFILE 或 performance_schema 查具体阶段耗时。这点容易漏掉。
