PostgreSQL EXPLAIN 入门：先找估算偏差，再决定要不要建索引
一条查询变慢，最容易冲动的做法是立刻给条件列加索引。但慢查询可能来自数据分布变化、返回结果过多、错误的行数估计，甚至应用网络与序列化。执行计划的价值，是把“感觉数据库慢”变成可检验的假设。本文以 PostgreSQL 18 文档为依据，示例表结构和参数需要替换。
AI生成概念配图：借助放大镜检查查询计划树中的关键节点，仅辅助理解，不代表真实界面或实测结果。
先只看计划，不急着执行
EXPLAIN SELECT id, created_at FROM orders WHERE customer_id = 42 ORDER BY created_at DESC LIMIT 20;
普通 EXPLAIN 展示优化器准备采用的计划。输出中的 cost 是规划成本单位，不是毫秒；rows 是该节点预计输出的行数，也不是“总共检查了多少行”。先保存原 SQL、参数类型、相关索引与计划，避免修改之后再也无法重现原问题。示例数字只是查询条件与返回条数，不是性能结论。
小表或需要读取大部分行时，顺序扫描可能是合理选择。索引也会增加写入与维护成本。判断索引是否有用，应结合过滤条件、排序、返回列和数据选择性，而不是把 Seq Scan 当作错误标签。先问查询实际需要多少数据，往往能发现不必要的 SELECT * 或缺少业务范围限制。
确有需要，再收集实际执行信息
BEGIN; SET LOCAL statement_timeout = '5s'; EXPLAIN (ANALYZE, BUFFERS, TIMING OFF) SELECT id, created_at FROM orders WHERE customer_id = 42 ORDER BY created_at DESC LIMIT 20; ROLLBACK;
ANALYZE 会真正执行语句。示例的五秒只是一项测试保护，应按环境调整；繁忙生产库仍应先评估负载与锁等待。TIMING OFF 关闭逐节点计时，但保留实际行数等执行信息，适合先定位估算问题。这里明确写出 BUFFERS，便于阅读，也避免把不同版本默认行为混为一谈。
不要把事务回滚当作无风险沙箱。写语句依然会产生工作量和锁，序列值等影响未必回滚，函数还可能触发外部副作用。对未知 SQL，先在隔离测试环境检查；即使是 SELECT，也要确认没有带副作用的函数。本文示例只展示普通读取，并不授权在生产中试跑任意语句。
按一个固定顺序读结果
先看估算 rows 与实际 rows 的差距，再看 loops。多次循环节点的实际行数和时间通常按每次执行平均展示，理解总工作量时要结合循环次数。然后沿树检查大量行在哪里进入、在哪里被过滤，以及排序或哈希是否使用临时文件。不要把父节点与子节点统计简单相加，它们可能包含重叠的工作。
BUFFERS 中的 hit 表示在 PostgreSQL 缓冲区中找到块，read 表示需要读取块；read 并不自动等价于物理磁盘访问，因为操作系统仍可能缓存。执行计划也不能完整代替客户端端到端计时。把数据库执行时间与接口耗时分开记录，才能判断下一步该查 SQL，还是查返回量与应用处理。
一次只改变一个可解释的因素
若估算明显偏离，可先检查统计信息是否过时，再评估是否需要 ANALYZE、提高统计粒度或处理相关列分布。若排序和过滤路径不合适，再设计候选索引并在测试环境比较。比较时固定参数、数据规模和缓存条件，保留改变前后的计划，而不是只挑一次较快的结果。
一个有用的排查结论应能说清：哪个节点造成了额外工作，为什么优化器作出当前选择，哪项改动改变了这一点，以及付出的写入或存储代价。不能说明这些时，先继续收集证据，比批量添加索引更稳妥。
