优化

副标题 / 摘要 慢查询不是靠猜，而是靠数据。本文给出从日志、监控到执行计划的完整定位路径。 目标读者 负责数据库性能的工程师 需要定位瓶颈的开发者 SRE / DBA 背景 / 动机 性能问题常常被误判为“代码慢”，其实可能是数据库查询失控。 系统化的慢查询定位流程能节省大量时间。 核心概念 慢查询日志：记录超过阈值的 SQL 执行计划（EXPLAIN）：查看索引与扫描方式 P95/P99：关注尾部延迟 查询归因：把 SQL 与请求链路对应起来 实践指南 / 步骤 开启慢查询日志 统计高频/高耗 SQL 用 EXPLAIN 分析执行计划 补齐索引或重写 SQL 验证优化效果（对比指标） 可运行示例 EXPLAIN SELECT * FROM orders WHERE user_id = 123; 解释与原理 慢查询可能来自全表扫描、索引失效、JOIN 不合理。 通过 EXPLAIN 可以看到查询是否走索引、扫描行数等关键指标。 常见问题与注意事项 索引越多越好吗？ 不是，索引会增加写入成本。 慢查询一定是 SQL 写错吗？ 不一定，也可能是统计信息过期或数据分布变化。 只看平均值会漏问题吗？ 会，要看 P95/P99。 最佳实践与建议 建立慢查询告警 结合 APM 定位调用链 优化后回归测试 小结 / 结论 定位慢查询需要从日志、指标、执行计划三层入手。 找到瓶颈后再谈优化，才是高效路径。 参考与延伸阅读 MySQL Slow Query Log PostgreSQL pg_stat_statements EXPLAIN 使用指南 元信息 阅读时长：7~9 分钟 标签：慢查询、数据库性能 SEO 关键词：Slow Query, EXPLAIN, 索引 元描述：系统化定位慢查询的方法与流程。 行动号召（CTA） 打开一次慢查询日志，挑出 TOP 3 SQL 先优化。