MySQL慢查询导致接口超时的一次复盘

2022年10月记录，分类「服务器运维」。这篇按当时的测试现场整理，重点放在目标、动作和可复用的检查点。

故障表现

这次接口超时一开始被怀疑是应用线程池不够，后来从慢日志看到某个列表查询扫描了几十万行。问题不复杂，但定位顺序很典型。

记录这篇的目的，是让下次遇到同类问题时少走一轮弯路。

定位过程

• 先拿接口参数复现慢请求，记录响应时间和 traceId。
• 在数据库里找对应 SQL，执行 EXPLAIN 看扫描行数。
• 加索引后用同一批数据回归，确认 p95 和慢日志都下降。

EXPLAIN SELECT * FROM orders WHERE user_id = 10001 ORDER BY created_at DESC LIMIT 20;
SHOW VARIABLES LIKE 'slow_query_log';

验证方式

• 执行计划命中预期索引。
• 分页、排序、筛选组合都覆盖。
• 新增索引没有明显拖慢写入接口。

这类内容最怕只靠口头传递，所以我会把命令、样本和异常分支一起留下。

改完以后

慢查询缺陷不要只写接口超时，要把 SQL、数据量、执行计划和优化前后对比一起给出来。后面遇到类似需求，可以先按这个结构跑一遍手工验证，再决定是否自动化。