慢查询优化

要解决什么问题

数据库查询变慢时，工程师通常面临两类困境：一是慢查询日志里的 SQL 看起来无法改进，二是ORM 层在生产环境中突然触发大量小查询。一个原本 200ms 的页面响应，可能因为一次全表扫描或 N+1 查询膨胀到数秒，甚至拖垮整个实例。这个技能要解决的正是这类可测量的数据库性能退化，而不是泛泛的“数据库优化”。

它如何工作

技能围绕一套可验证的流程展开：

• 定位慢查询：从慢查询日志、APM 或用户反馈中收集目标 SQL，记录执行耗时、表规模与调用频率。高频慢查询优先级高于偶发查询。
• 分析执行计划：对 PostgreSQL 使用 EXPLAIN ANALYZE，对 MySQL 使用 EXPLAIN FORMAT=JSON。重点关注全表扫描、高估算行的嵌套循环连接、未索引列排序，以及估算行数与实际行数之间的差异。
• 识别优化机会：为 WHERE、JOIN、ORDER BY 涉及的列添加索引；将子查询改写为 JOIN；用具体列替换 SELECT *；在合适位置添加 LIMIT；使用覆盖索引避免回表；消除冗余条件。
• 逐项应用优化：每次只改动一处，以便独立衡量效果。对于 N+1 问题，将懒加载改为预加载（如 Django 的 select_related/prefetch_related、Prisma 的 include、SQLAlchemy 的 joinedload）。
• 测量与验证：对优化后的查询再次运行 EXPLAIN ANALYZE，对比执行时间、扫描行数与计划结构，确认结果一致，并检查新索引是否显著影响写入性能。
• 配置持续监控：在 PostgreSQL 中启用 log_min_duration_statement（如 100ms 阈值），结合 pg_stat_statements、Datadog、Grafana 等工具追踪查询趋势。

支持 PostgreSQL、MySQL 以及 SQLAlchemy、Django ORM、Prisma、ActiveRecord、Sequelize、TypeORM 等常见 ORM，并可对接 pganalyze、Datadog APM、New Relic、Grafana + Prometheus 等监控体系。

适用边界与注意点

• 不要只用 EXPLAIN：缺少 ANALYZE 的执行计划只提供估算值，实际行数与耗时可能偏差很大。
• 复合索引要匹配查询模式：例如 (status, ordered_at) 的复合索引通常优于两列各自建索引，因为可以走一次索引范围扫描。
• 避免 SELECT *：宽行增加 I/O，也阻碍覆盖索引生效。
• 关注统计信息偏移：大批量导入后，查询规划器可能仍使用过期统计信息，需要运行 ANALYZE 或 ANALYZE TABLE 刷新。
• 警惕索引膨胀：高写入表上的频繁更新和删除会使索引体积膨胀，定期 REINDEX 或 OPTIMIZE TABLE。
• ORM 生成的 SQL 不总是最优：有时 ORM 会生成不必要的 LEFT JOIN 或子查询，可用 Django 的 QuerySet.query 或 Knex 的 .toSQL() 检查实际 SQL，并在必要时覆盖。