MySQL慢查询日志：找到那些偷偷变慢的SQL
MySQL慢查询日志：找到那些偷偷变慢的SQL
目录
- 慢查询日志是什么
- 开启慢查询日志
- 慢查询日志长什么样
- mysqldumpslow：日志分析工具
- 配合 EXPLAIN 做深度分析
- 常见问题排查清单
- 小结
慢查询日志是什么
慢查询日志是 MySQL 提供的一个功能，它会把执行时间超过指定阈值的 SQL 语句记录到文件里。
有了慢查询日志，你就不用一行一行翻代码去猜哪条 SQL查询较慢可能存在问题，直接看日志就可以找到问题SQL。
MySQL 默认是关闭慢查询日志的，因为记录日志本身有性能开销，所以生产环境通常只在排查问题时临时开启，或者设置一个相对严格的阈值（比如 1 秒），只记录真正有问题的 SQL。
开启慢查询日志
查看当前状态
-- 查看慢查询日志是否开启SHOWVARIABLESLIKE'slow_query_log';-- 查看阈值（单位：秒）SHOWVARIABLESLIKE'long_query_time';-- 查看日志文件路径SHOWVARIABLESLIKE'slow_query_log_file';正常情况下，slow_query_log的值是OFF，long_query_time默认是 10 秒。10 秒太宽松了，生产环境一般设成 1 秒甚至 0.5 秒，主要还是取决于业务场景。
临时开启（当前会话生效）
-- 开启慢查询日志SETGLOBALslow_query_log='ON';-- 设置阈值为 1 秒（超过 1 秒的 SQL 才记录）SETGLOBALlong_query_time=1;-- 可选：记录没有使用索引的 SQLSETGLOBALlog_queries_not_using_indexes='ON';用SET GLOBAL设置的参数在 MySQL 重启后会失效，下次启动还是用配置文件里的值。
永久开启（修改配置文件）
编辑 MySQL 的配置文件my.cnf（Linux）或my.ini（Windows），在[mysqld]段落下添加：
[mysqld] # 开启慢查询日志 slow_query_log = 1 # 慢查询阈值：1 秒 long_query_time = 1 # 日志文件路径（可以自定义） slow_query_log_file = /var/log/mysql/slow.log # 可选：记录没有使用索引的 SQL log_queries_not_using_indexes = 1修改之后重启 MySQL，或者执行SET GLOBAL命令让配置立即生效。
一个小技巧：log_queries_not_using_indexes这个参数很实用。它会把所有没走索引的 SQL 都记录下来，不管执行时间多长。这类 SQL 在数据量小的时候可能跑得很快，但随着数据增长会越来越慢，属于"定时炸弹"，有了这个功能就可以早点发现早点处理。
慢查询日志长什么样
开启之后，我们来制造一条慢查询，看看日志长什么样。
先准备一张测试表和一些数据：
CREATETABLEuser_order(idBIGINTPRIMARYKEYAUTO_INCREMENT,user_idBIGINTNOTNULL,order_noVARCHAR(32)NOTNULL,amountDECIMAL(10,2),statusVARCHAR(20),create_timeDATETIME,INDEXidx_user_id(user_id))ENGINE=InnoDB;-- 插入 100 万条测试数据DELIMITER//CREATEPROCEDUREgenerate_orders(INnINT)BEGINDECLAREiINTDEFAULT0;WHILEi<nDOINSERTINTOuser_order(user_id,order_no,amount,status,create_time)VALUES(FLOOR(RAND()*10000),CONCAT('ORD',LPAD(i,10,'0')),ROUND(RAND()*1000,2),ELT(FLOOR(RAND()*3)+1,'pending','paid','cancelled'),DATE_SUB(NOW(),INTERVALFLOOR(RAND()*365)DAY));SETi=i+1;ENDWHILE;END//DELIMITER;CALLgenerate_orders(1000000);现在执行一条故意不走索引的查询：
-- 对 status 做模糊查询，status 上没有索引SELECT*FROMuser_orderWHEREstatusLIKE'p%'ORDERBYcreate_timeDESCLIMIT50;等它跑完（可能要几秒），然后去日志文件里找找看。日志文件的路径可以用SHOW VARIABLES LIKE 'slow_query_log_file'查看。
一条典型的慢查询日志长这样：
# Time: 2026-06-21T14:32:05.123456+08:00 # User@Host: root[root] @ localhost [] Id: 42 # Query_time: 2.356789 Lock_time: 0.000123 Rows_sent: 50 Rows_examined: 1000000 SET timestamp=1718946725; SELECT * FROM user_order WHERE status LIKE 'p%' ORDER BY create_time DESC LIMIT 50;逐行解读：
| 字段 | 含义 | 重点关注 |
|---|---|---|
| Time | SQL 执行的时间点 | 定位问题发生的时刻 |
| User@Host | 执行 SQL 的用户和来源 | 排查是不是某个服务在搞事 |
| Query_time | SQL 执行总耗时（秒） | 核心指标，越小越好 |
| Lock_time | 等待锁的时间（秒） | 如果很大，说明有锁竞争 |
| Rows_sent | 返回给客户端的行数 | 和 LIMIT 对比，看有没有多返回 |
| Rows_examined | 扫描的行数 | 核心指标，越大说明越低效 |
| SQL 语句 | 实际执行的 SQL | 拿去 EXPLAIN 分析 |
最该关注的两个数字：Query_time 和 Rows_examined。
Query_time 告诉你这条 SQL 到底慢不慢，Rows_examined 告诉你它为什么慢。如果 Rows_examined 是 100 万，但 Rows_sent 只有 50，说明 MySQL 扫了 100 万行才挑出 50 条——这就是典型的索引缺失或索引失效。
mysqldumpslow：日志分析工具
日志文件看几条还行，但如果慢查询很多，一条条翻就太低效了。MySQL 自带了一个日志分析工具mysqldumpslow，可以帮我们做汇总统计。
# 按执行时间排序，取前 10 条最慢的mysqldumpslow-st-t10/var/log/mysql/slow.log# 按扫描行数排序，取前 10 条mysqldumpslow-sr-t10/var/log/mysql/slow.log# 按执行次数排序，取前 10 条mysqldumpslow-sc-t10/var/log/mysql/slow.log参数说明：
| 参数 | 含义 |
|---|---|
-s t | 按总执行时间排序（默认） |
-s r | 按扫描总行数排序 |
-s c | 按执行次数排序 |
-s l | 按锁等待时间排序 |
-t N | 只显示前 N 条 |
-g "pattern" | 只匹配包含指定字符串的 SQL |
输出结果类似：
Count: 125 Time=2.36s (295s) Lock=0.00s (0.15s) Rows=50.0 (6250), root[root]@localhost SELECT * FROM user_order WHERE status LIKE 'S' ORDER BY create_time DESC LIMIT N这一行告诉我们：这条 SQL 在统计时段内执行了 125 次，平均耗时 2.36 秒，累计耗时 295 秒，平均扫描行数 6250 条。
Count 大的说明是高频 SQL，Time 大的说明是耗时大户。如果一条 SQL Count 和 Time 都大，那它就是性能优化的第一优先级。
配合 EXPLAIN 做深度分析
慢查询日志帮你找到了"嫌疑人"，但要定罪还需要充分的证据。所以在拿到日志里的 SQL 后，我们继续用EXPLAIN看看它的执行计划：
EXPLAINSELECT*FROMuser_orderWHEREstatusLIKE'p%'ORDERBYcreate_timeDESCLIMIT50;输出可能是：
+----+------+-------+------+---------+------+----------+-----------------------------+ | id | type | key | ref | rows | filtered | Extra | +----+------+-------+------+---------+----------+------------------------------------+ | 1 | ALL | NULL | NULL | 1000000 | 33.33 | Using where; Using filesort | +----+------+-------+------+---------+----------+------------------------------------+四个危险信号：
- type = ALL：全表扫描，没走索引
- key = NULL：没有可用索引
- rows = 1000000：扫描了 100 万行
- Extra = Using filesort：额外排序
和日志里的 Rows_examined = 1000000 对上了。问题很明确：status列没有索引，MySQL 只能全表扫描。
优化方案：给status加索引，或者改成联合索引(status, create_time)同时覆盖过滤和排序：
ALTERTABLEuser_orderADDINDEXidx_status_time(status,create_time);再查一次 EXPLAIN：
+----+-------+----------------+------+---------+------+----------+-------+ | id | type | key | ref | rows | filtered | Extra | +----+-------+----------------+------+---------+----------+-------------+ | 1 | range | idx_status_time| NULL | 333333 | 100.00 | Using where | +----+-------+----------------+------+---------+----------+-------------+type 从 ALL 变成了 range，rows 从 100 万降到了 33 万，Using filesort 也没了。执行时间从 2 秒多降到几百毫秒。
慢查询日志负责"发现问题"，EXPLAIN 负责"定位原因"，两者配合才是完整的调优链路。
常见问题排查清单
拿到慢查询日志后，按照这个清单逐项检查：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| Rows_examined 远大于 Rows_sent | 索引缺失或索引失效 | EXPLAIN 看 type 和 key |
| Query_time 大但 Rows_examined 不大 | 锁等待、IO 等待 | 关注 Lock_time，检查是否有表锁 |
| 同一条 SQL 时快时慢 | 执行计划不稳定 | EXPLAIN 看是否有多个候选索引 |
| 日志里出现大量相同 SQL | 慢查询集中在某几张表 | mysqldumpslow -s c 统计频次 |
| 某个时间段集中出现慢查询 | 定时任务、批量导入 | 检查 Time 字段的时间分布 |
| Lock_time 很大 | 有事务长时间未提交 | 检查SHOW ENGINE INNODB STATUS |
一个实用的排查流程：
小结
**慢查询日志是 MySQL 性能排查的起点。**它帮你从海量 SQL 中筛选出真正有问题的那些，附上执行时间、扫描行数等关键指标，让你的调优工作有的放矢。
从实际操作来看，慢查询日志 + EXPLAIN 是一对黄金搭档。前者负责"发现"，后者负责"诊断"。发现问题是第一步，解决问题是第二步，在后端面试之中遇到“mysql如何调优”这个问题，我们就可以采用这个思路进行回答。在实际工作生产环境中，我们依然使用这个思路进行实际的排查优化。