副标题 / 摘要

慢查询不是靠猜，而是靠数据。本文给出从日志、监控到执行计划的完整定位路径。

目标读者

  • 负责数据库性能的工程师
  • 需要定位瓶颈的开发者
  • SRE / DBA

背景 / 动机

性能问题常常被误判为“代码慢”，其实可能是数据库查询失控。
系统化的慢查询定位流程能节省大量时间。

核心概念

  • 慢查询日志：记录超过阈值的 SQL
  • 执行计划（EXPLAIN）：查看索引与扫描方式
  • P95/P99：关注尾部延迟
  • 查询归因：把 SQL 与请求链路对应起来

实践指南 / 步骤

  1. 开启慢查询日志
  2. 统计高频/高耗 SQL
  3. 用 EXPLAIN 分析执行计划
  4. 补齐索引或重写 SQL
  5. 验证优化效果（对比指标）

可运行示例

EXPLAIN SELECT * FROM orders WHERE user_id = 123;

解释与原理

慢查询可能来自全表扫描、索引失效、JOIN 不合理。
通过 EXPLAIN 可以看到查询是否走索引、扫描行数等关键指标。

常见问题与注意事项

  1. 索引越多越好吗？
    不是，索引会增加写入成本。

  2. 慢查询一定是 SQL 写错吗？
    不一定，也可能是统计信息过期或数据分布变化。

  3. 只看平均值会漏问题吗？
    会，要看 P95/P99。

最佳实践与建议

  • 建立慢查询告警
  • 结合 APM 定位调用链
  • 优化后回归测试

小结 / 结论

定位慢查询需要从日志、指标、执行计划三层入手。
找到瓶颈后再谈优化，才是高效路径。

参考与延伸阅读

  • MySQL Slow Query Log
  • PostgreSQL pg_stat_statements
  • EXPLAIN 使用指南

元信息

  • 阅读时长：7~9 分钟
  • 标签：慢查询、数据库性能
  • SEO 关键词：Slow Query, EXPLAIN, 索引
  • 元描述：系统化定位慢查询的方法与流程。

行动号召（CTA）

打开一次慢查询日志，挑出 TOP 3 SQL 先优化。