华为云 RDS for MySQL 慢查询排查的五个步骤

慢查询排查别从 EXPLAIN 开始

很多人一发现慢查询就直接 EXPLAIN。但如果连“哪条 SQL 慢、慢在什么阶段”都不清楚，EXPLAIN 往往是在猜。我的习惯是按下面五步走，先定位再分析。

第一步：确认慢查询日志真的开着

long_query_time 默认 10 秒，很多慢在 1~3 秒的 SQL 根本不会进日志。生产上一般调到 1 秒，并确认 slow_query_log 为 ON。

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

第二步：按总耗时排序，而不是按单次最慢

mysqldumpslow 或 pt-query-digest 都能做聚合。关键看总耗时占比：一条 0.5 秒但每秒执行 100 次的 SQL，危害远大于一条偶发的 8 秒大查询。先治高频的那条。

第三步：看执行计划里的三个信号

EXPLAIN FORMAT=JSON SELECT ...;

重点看三处：

• type 是否为 ALL（全表扫描）或 index（全索引扫描）
• rows 估算行数是否远大于实际返回行数
• Extra 是否出现 Using filesort、Using temporary

出现 filesort 说明排序没走索引，出现 temporary 说明用了临时表，这两个在数据量上来后会急剧恶化。

第四步：区分是 SQL 问题还是负载问题

同一个 SQL 在低峰期快、高峰期慢，往往不是索引问题，而是并发或锁等待。这时候要看：

SHOW ENGINE INNODB STATUS;
SELECT * FROM performance_schema.data_lock_waits;

如果是锁等待，优化 SQL 没用，要改事务粒度或加读写分离。

第五步：改完之后必须回归验证

加索引后要确认两件事：执行计划真的变了（rows 明显下降），以及写入没有明显变慢。索引不是越多越好，联合索引的顺序错了等于白加。

一个常被忽略的点

RDS 控制台的慢日志查询方便，但默认只保留有限天数，且采样可能有延迟。做长期分析建议自己把慢日志采集出去，落到 OBS 或自建表里，比在控制台翻页靠谱。

排查慢查询的收益不在“解决这一条”，而在于把这类问题模式化，下次遇到同类能直接跳到结论。不做这一步，每次都在重新摸索。