技能介绍

先解决什么问题

当报表接口在高峰期突然变慢，或者 ORM 一次列表页触发上百条 SQL，根因通常不是“数据库不够快”，而是执行计划偏离预期：大表上出现顺序扫描，过滤列缺少合适索引，子查询被反复执行，或者 SELECT * 放大 IO。这个技能面向已经在运行的系统，把“慢”拆成可验证的证据链。

工作方式与关键步骤

核心能力包括使用 EXPLAIN ANALYZE 读取 PostgreSQL 执行计划，或 EXPLAIN FORMAT=JSON 分析 MySQL；识别缺失索引、低效连接、排序代价和 N+1；给出索引创建语句、查询改写方案或 ORM 急加载修改；最后重新执行计划对比耗时、扫描行数和结果一致性。

工作流程：

收集慢查询：从慢查询日志、APM 或用户反馈中定位问题，记录执行时间、表规模和频率。
解释执行计划：查看实际扫描方式、估算行数与实际行数的差距，寻找顺序扫描、嵌套循环和排序代价。
提出修复：为 WHERE、JOIN、ORDER BY 列补索引；把子查询改成 JOIN；减少 SELECT *；必要时使用覆盖索引。
修复 N+1：在 Django 使用 select_related / prefetch_related，SQLAlchemy 使用 joinedload，Prisma 使用 include。
验证结果：确认返回数据一致，比较前后耗时，并检查写入路径是否因新增索引而劣化。
持续观察：启用慢查询阈值，配合 pg_stat_statements、Datadog、Grafana 等工具跟踪趋势。

适用边界与注意点

它适合已有 SQL、ORM 代码和可执行 EXPLAIN 的环境，不等于自动数据库调优平台。优化应逐步应用，一次只改一项，否则无法归因。统计信息漂移或计划缓存可能导致执行计划变化，必要时先刷新统计。新索引会加快读、加重写，写入密集表必须做基准测试。视图里的相关子查询、ORM 生成的多余 JOIN，也可能需要展开后用原生 SQL 兜底。