SQL 执行计划中的关键字段解读_技术教程

cost不是执行时间，而是优化器基于统计信息估算的相对开销单位，受seq_page_cost等参数影响；rows和width共同决定内存与网络开销；Buffers中shared hit高不等于快；Parallel Aware仅表示支持并行，需满足多项条件才实际启用。

cost 是 PostgreSQL 执行计划里最常被误解的字段。它不是毫秒，也不是 CPU 时间，而是优化器基于统计信息估算的“相对开销单位”。这个值由 seq_page_cost、random_page_cost、cpu_tuple_cost 等配置加权计算得出。

实际执行快慢和 cost 高低不一定一致：比如一个 cost=1000 的索引扫描可能比 cost=5000 的并行顺序扫描更快（尤其当数据已缓存时）
修改 random_page_cost 会影响所有依赖随机读的算子（如 Index Scan、Bitmap Heap Scan）的 cost 计算结果
如果你发现 cost 和真实耗时严重偏离，大概率是表统计信息过期，先运行 VACUUM ANALYZE table_name

rows 是优化器预估的该节点输出行数，width 是单行平均字节数。这两个值共同决定中间结果集的内存占用和网络传输量。

width 偏高（比如选了大量 text 或 jsonb 字段）会导致 Sort、Hash Join 更容易溢出到磁盘（disk 标记出现）
rows 严重低估（常见于未 ANALYZE 的大表或复杂谓词）会让优化器错误选择嵌套循环（Nested Loop），实际执行时外层每行都触发一次内层全表扫描
可用 EXPLAIN (ANALYZE, BUFFERS) 对比预估 rows 和实际 actual rows，差 10 倍以上就该检查统计信息或重写条件

Bu

ffers 行只在加 ANALYZE 选项后才出现，反映物理/逻辑块访问情况。但 “hit 高 ≠ 快” 是典型误区。

shared hit 高说明数据在 shared_buffers 内，但若命中的是冷数据（刚被刷入 buffer 但尚未被预热），仍需等待 I/O 完成初始化
更关键的是看 read 和 write：哪怕 hit=99%，只要某次 write=1200（例如大排序落盘），就会拖慢整体响应
注意 local 和 temp buffers：临时表或 CTE 物化会走 temp，其性能受 temp_buffers 设置限制，和 shared_buffers 无关

PostgreSQL 10+ 中，Parallel Aware 仅表示该节点支持并行，不代表一定会并行执行。

必须同时满足：查询不含不支持并行的构造（如 FOR UPDATE、某些窗口函数）、max_parallel_workers_per_gather > 0、优化器认为并行收益大于开销（通常 cost > 100000 才考虑）
即使满足，也可能因资源竞争被降级：比如 work_mem 不足导致并行 worker 无法分配足够内存，自动退回到单线程
检查是否真并行，不能只看 Parallel Aware，而要看执行计划中是否有 Gather 节点及其子节点是否带 (cost=... rows=... width=...) (actual time=... rows=... loops=...) 多次重复（loops > 1）

执行计划不是静态快照，每个字段背后都连着配置、统计、硬件和查询结构四层变量。调优时盯着单个值容易误判，真正要对齐的是「估算逻辑」和「运行时行为」之间的断层。