mysql慢查询日志是什么_mysql性能分析概念_技术教程

slow_query_log 是 MySQL 控制慢查询记录的运行时开关，实际日志由 slow_query_log_file 指定文件或 mysql.slow_log 表存储；需通过 SHOW VARIABLES 验证 ON 状态、long_query_time 阈值、log_output 输出方式，并慎用 log_queries_not_using_indexes。

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）日志交叉验证。