slow_query_log是 MySQL 内置的性能诊断开关，不是“日志文件”本身，而是一个运行时标记——它控制 MySQL 是否把超时查询写入日志。真正记录内容的是
slow_query_log_file指向的文件（或
mysql.slow_log表），里面存着原始 SQL、执行时间、锁等待、行扫描数等关键现场信息。
怎么确认慢查询日志是否真在工作？
很多人改了配置却看不到日志，根本原因是：只设了参数，没验证状态是否生效。
SHOW VARIABLES LIKE 'slow_query_log'返回
ON才算开启成功；
OFF表示配置未加载或被动态关闭过
SHOW VARIABLES LIKE 'long_query_time'查看阈值——注意：默认是
10.000000秒，不是 1 秒；生产环境建议设为
0.5或
1，否则大量真实慢 SQL 会被漏掉
SHOW VARIABLES LIKE 'log_output'确认输出方式：
FILE（写入磁盘） or
TABLE（写入
mysql.slow_log）；
TABLE方便用 SQL 查询，但会轻微拖慢慢查询本身，不建议长期开启 临时开启可用：
SET GLOBAL slow_query_log = ON;但 MySQL 重启后失效；永久生效必须写进
/etc/my.cnf的
[mysqld]段并重启服务
为什么 log_queries_not_using_indexes
要慎开？
这个参数看似“帮你看漏索引”，实则是把所有无索引的
SELECT都塞进慢日志——哪怕执行只要 0.002 秒。在高并发小查询场景下，它会让慢日志瞬间膨胀数倍，掩盖真正耗时的语句。 仅在专项索引治理期短期开启（比如上线前做全量扫描检查） 日常监控中，它产生的日志噪音远大于价值；不如用
pt-query-digest配合
--filter过滤出
Rows_examined > 1000的语句更精准 开启后务必配合
long_query_time = 0，否则两者逻辑冲突（MySQL 会优先按时间阈值过滤，再判断是否用索引）
分析日志时，别只盯着 Query_time
一条 SQL 耗时 5 秒，不等于它“写得差”。慢日志里每条记录包含多个时间维度，必须交叉比对：
Query_time：总耗时（含锁等待、调度延迟）
Lock_time：真正被锁住的时间——如果接近
Query_time，说明是锁争用问题，不是 SQL 本身问题
Rows_examined：扫描行数；若远大于
Rows_sent（返回行数），大概率缺索引或条件没走索引
Rows_affected（DML）或
tmp_tables/
tmp_disk_tables：暴露出内存不足、排序/分组落盘等隐性瓶颈
例如这条日志片段：
# Query_time: 4.238712 Lock_time: 3.982101 Rows_examined: 128000 Rows_sent: 1
——真正执行只花了 0.25 秒，其余时间都在等锁，优化方向应是事务拆分或加索引减少锁范围，而不是重写 WHERE 条件。
用 pt-query-digest
分析前，先做两件事
直接跑
pt-query-digest /var/log/mysql/slow.log很容易得到一堆无效聚合（比如带随机 ID 的查询被当成不同语句）。必须预处理： 加
--filter '$event->{db} and $event->{db} =~ m/^prod_/i' 只分析生产库，避免测试数据干扰
加 --group-by fingerprint（默认行为），确保
WHERE id = 123和
WHERE id = 456归为同一类，否则统计失去意义 避免分析实时滚动的日志文件（如
mysql-slow.log.1），优先用
cp复制快照再分析，防止文件被轮转或截断导致解析失败
真正有价值的报告不是“最慢的 10 条 SQL”，而是 “Top 5 占用 73% 总响应时间的指纹模板” —— 它告诉你该优先优化哪一类业务逻辑。
最容易被忽略的一点：慢查询日志只记录“已执行完”的语句。如果 SQL 在执行中途被 kill、超时中断、或卡死在连接池层，它根本不会出现在日志里。这时候得结合
SHOW PROCESSLIST、Performance Schema 或代理层（如 ProxySQL）日志交叉验证。
