1. 课程导入与性能治理全景

复杂查询性能治理，不是“把慢 SQL 调快”这么简单。它要解决的是一个系统性问题：在给定硬件、数据规模、并发压力和业务语义约束下，让一条 SQL 的响应时间、资源消耗和结果正确性同时达到可接受水平。因此，本课程的第一件事，是明确治理的目标、边界与核心对象，并建立从 SQL 文本到执行计划的诊断视角。

治理目标与边界

性能治理的目标可以拆成三个层次。第一层是响应时间：用户或上游系统等待结果的时间，通常用 P95、P99 而非平均值衡量。第二层是资源效率：一条查询消耗了多少 CPU、内存、I/O 和临时空间，是否挤占了其他会话。第三层是稳定性：在数据增长、并发升高或统计信息变化时，性能是否可预期，而不是今天快、明天慢。

边界同样重要。性能治理不负责改变业务语义，也不应通过“加索引”掩盖数据模型缺陷。它关注的是：SQL 写法、执行计划、统计信息、索引结构、参数化方式、并发控制以及数据库配置之间的匹配关系。超出这个范围的问题，例如网络带宽不足、应用层序列化开销，需要与相应团队协同，而不是在数据库内强行解决。

核心对象：从 SQL 文本到执行计划

PostgreSQL 的查询处理链路可以概括为：SQL 文本 → 解析（Parse）→ 重写（Rewrite）→ 计划（Plan）→ 执行（Execute）。解析阶段把文本变成语法树，重写阶段展开视图和规则，计划阶段由优化器基于统计信息、代价模型和可用索引生成执行计划，执行阶段由执行器按计划树逐节点拉取数据。

性能问题几乎都发生在这条链路的某个环节。例如：解析和重写阶段可能因为复杂视图嵌套导致计划膨胀；计划阶段可能因为统计信息过期选错连接方式；执行阶段可能因为嵌套循环次数过多导致 I/O 放大。因此，诊断视角必须从“SQL 文本”上升到“执行计划”，再结合运行时指标定位瓶颈。

如何建立诊断视角

诊断的第一步，是拿到真实执行计划。在 PostgreSQL 中，最常用的命令是：

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT o.order_id, c.customer_name, SUM(oi.amount)
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN order_items oi ON oi.order_id = o.order_id
WHERE o.created_at >= '2024-01-01'
GROUP BY o.order_id, c.customer_name
ORDER BY SUM(oi.amount) DESC
LIMIT 20;

其中 ANALYZE 会真正执行查询并返回实际行数与耗时，BUFFERS 会显示共享缓冲区命中与磁盘读取情况。阅读计划时，重点看三件事：估算行数与实际行数是否偏差过大、最耗时的节点是哪一个、是否存在重复扫描或临时文件。如果估算行数与实际行数相差一个数量级以上，通常意味着统计信息不足或数据分布倾斜，优化器很可能选错了连接方式或访问路径。

一个典型瓶颈的定位示例

假设上述查询在数据量增长后从 200ms 恶化到 8s。执行计划显示：Nested Loop 内层对 order_items 做了约 12 万次索引扫描，实际行数远大于估算行数。这说明优化器低估了 orders 过滤后的行数，选择了嵌套循环而非哈希连接。此时治理动作不是直接加索引，而是先更新统计信息：

ANALYZE orders;
ANALYZE order_items;
ANALYZE customers;

如果统计信息更新后计划仍不理想，再检查 created_at 与 customer_id 的联合选择性，评估是否需要扩展统计信息或调整索引列顺序。这个例子说明：性能治理必须沿着“文本 → 计划 → 运行时”的链路逐层排查，而不是凭经验猜测。

本课程的组织方式

后续章节将围绕这条链路展开：先讲执行计划的阅读方法与代价模型，再讲统计信息、索引选择、连接算法、子查询与 CTE 的优化策略，最后进入并发、锁、临时文件与参数调优等运行时问题。每一节都会给出可复现的示例、判断依据和治理动作，帮助你把“看懂计划”转化为“改对计划”。