explain analyze 会真实执行查询并返回实际性能数据，而 explain 仅生成预估执行计划；必须用事务包裹写操作以避免数据变更，且需结合 analyze 表更新统计信息确保估算准确。
如果您执行一条 PostgreSQL 查询并希望了解其真实运行行为与性能瓶颈，则必须使用 EXPLAIN ANALYZE 获取实际执行统计。以下是深度解析该命令输出的多个关键维度：
一、理解 ANALYZE 与非 ANALYZE 的本质区别
EXPLAIN 默认仅触发查询规划器生成预估计划，不执行语句；而 EXPLAIN ANALYZE 会真正执行 SQL 并收集运行时指标。这一差异直接决定您能否发现统计失真、缓存失效或计划误选等深层问题。
1、执行前确认事务隔离级别，避免 ANALYZE 引发不可预期的锁等待或长事务阻塞。
2、对写操作（INSERT/UPDATE/DELETE）使用 ANALYZE 时，必须包裹在事务中：先执行 BEGIN，再执行 EXPLAIN ANALYZE，最后执行 ROLLBACK。
3、若目标表被频繁更新，需同步检查是否已执行 ANALYZE table_name 更新统计信息，否则 estimated rows 与 actual rows 偏差可能超过一个数量级。
二、逐层解读执行计划树的节点结构
PostgreSQL 执行计划为自底向上执行的树形结构，每个缩进层级代表子操作依赖关系。根节点为最终输出操作（如 Sort 或 Hash Join），叶子节点为数据源扫描（如 Seq Scan 或 Index Scan）。
1、识别节点类型：关注 Seq Scan、Index Scan、Index Only Scan、Bitmap Heap Scan、Hash Join、Nested Loop、Merge Join 等关键词，其中 Index Only Scan 表示完全无需访问堆页，性能最优。
2、观察缩进对齐：同一缩进层级的多个节点属于同一父操作的并行子路径；更深缩进表示该节点是上层节点的输入来源。
3、定位最耗时节点：在 ANALYZE 输出中查找 actual time= 数值最大且 loops>1 的节点，此类节点常暴露嵌套循环放大效应或低效过滤。
三、成本字段与实际时间的对照验证
cost=启动成本..总成本 是优化器基于统计信息和配置参数（如 random_page_cost）计算出的抽象开销，而 actual time=启动毫秒..总毫秒 是实测值。二者显著偏离时，说明模型假设与现实脱节。
1、比较 estimated rows 与 actual rows：若比值低于 0.5 或高于 2.0，表明统计信息严重滞后，应立即执行 ANALYZE table_name。
2、检查 cost 单位合理性：默认 seq_page_cost=1.0，random_page_cost=4.0；若系统使用 SSD，建议将 random_page_cost 调整为 1.1–1.3，否则优化器将持续低估索引扫描代价。
3、注意启动时间异常：当某节点 actual time 的启动部分（..前数值）远高于总时间，可能暗示前期资源争用（如 buffer pin wait 或 LWLock suspension）。
四、Buffers 缓冲区统计的诊断价值
Buffers 行显示共享缓冲区、本地缓冲区及临时缓冲区的读写次数，是判断 I/O 效率的核心依据。该字段仅在启用 BUFFERS 选项时出现，必须显式指定。
1、解析 Buffers 字段格式：例如 Buffers: shared read=120, local hit=45 中，read 表示物理读，hit 表示缓存命中。
2、计算缓存命中率：以 shared 缓冲区为例，公式为 hit / (hit + read)；低于 95% 需检查 work_mem 是否过小导致频繁落盘，或 shared_buffers 设置不足。
3、识别临时文件膨胀：若出现 temp read=890, temp written=1240，表明排序或哈希操作溢出内存，应调高 work_mem 或重写查询减少中间结果集规模。
五、Filter 与 Rows Removed by Filter 的性能警示
Filter 行显示节点内应用的谓词条件，Rows Removed by Filter 则量化该条件筛除的无效行数。该数值过大往往意味着索引未覆盖查询条件，或条件顺序未被有效下推。
1、定位低效 Filter：若某 Seq Scan 节点显示 Rows Removed by Filter: 98765 且 estimated rows 接近 total rows，说明全表扫描后才过滤，应建立对应列的索引。
2、验证组合索引有效性：对 WHERE a = ? AND b > ? 类查询，需确保索引列为 (a, b) 而非 (b, a)，否则 b 上的范围条件无法利用索引右侧。
3、警惕隐式类型转换：当 Filter 显示 city='Beijing'::text，若 city 列为 varchar 类型而查询字面量无类型标注，可能导致索引失效，应统一显式声明类型或修改列定义。
