慢查询日志

做的事：真实把阈值调低，跑一快一慢两条查询

代码SET GLOBAL slow_query_log=1; SET GLOBAL long_query_time=0.1; SET GLOBAL slow_query_log_file='/tmp/real_slow.log'; SELECT SLEEP(0.3); -- 真实耗时0.3秒，超过阈值 SELECT 1; -- 真实耗时几乎为0

验证：日志里真实只有那条慢的，精确记录到微秒

实测 · 本机/tmp/real_slow.log真实的内容

# Time: 2026-09-28T11:31:58.366542Z
# User@Host: root[root] @ localhost []  Id:   909
# Query_time: 0.342315  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 1
use mysqllab;
SET timestamp=1790595118;
SELECT SLEEP(0.3);

日志里真实只出现了SELECT SLEEP(0.3)这一条，Query_time真实精确记到了0.342315秒(比SLEEP参数本身的0.3秒略多一点，真实包含了查询解析、结果返回这些额外开销)。紧接着跑的SELECT 1真实完全没有出现在日志里——它的耗时远低于0.1秒的阈值。

结论：慢查询日志真实只按耗时筛选，不管查询"看起来"复杂不复杂

慢查询日志的判断标准真实极其简单粗暴：一条查询从开始到结束的真实耗时，是否超过long_query_time这个阈值，仅此而已——不管这条查询是不是一个语法上很"重"的多表JOIN，也不管它真实扫描了多少行数据，只要真实跑得够快，就不会被记录；反过来一条语法很简单的SELECT SLEEP(...)，只要真实耗时够久，一样会被记下来。真实用慢查询日志排查性能问题时，日志里Rows_examined这个字段(本文这条查询真实是1，因为SLEEP()本身不涉及表扫描)往往比"这条SQL看起来复杂不复杂"更能说明真实的性能问题所在——真实扫描行数远大于返回行数(Rows_sent)的查询，通常才是索引缺失或者索引选择性不够的真实信号。

分步演示：一快一慢，慢查询日志的真实取舍

每一步都是本文上面用真实的慢查询日志文件跑出来的原始结果。

只看耗时，不看查询'长得复杂不复杂'

这一步新验证的查询

本文用到的工具

本机 MySQL 26.7.0（InnoDB），真实的slow_query_log + long_query_time=0.1秒

下一篇 · MYSQL / INNODB 112

Performance Schema