cost不是执行时间，而是优化器基于统计信息估算的相对开销单位，受seq_page_cost等参数影响；rows和width共同决定内存与网络开销；Buffers中shared hit高不等于快；Parallel Aware仅表示支持并行，需满足多项条件才实际启用。
什么是 cost，它真的代表执行时间吗？
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 怎么影响内存与网络开销？
rows 是优化器预估的该节点输出行数，width 是单行平均字节数。这两个值共同决定中间结果集的内存占用和网络传输量。
-
width偏高（比如选了大量text或jsonb字段）会导致Sort、Hash Join更容易溢出到磁盘（disk标记出现） -
rows严重低估（常见于未ANALYZE的大表或复杂谓词）会让优化器错误选择嵌套循环（Nested Loop），实际执行时外层每行都触发一次内层全表扫描 - 可用
EXPLAIN (ANALYZE, BUFFERS)对比预估rows和实际actual rows，差 10 倍以上就该检查统计信息或重写条件
为什么 Buffers 显示 shared hit=12345 却还是很慢？
Buffers 行只在加 ANALYZE 选项后才出现，反映物理/逻辑块访问情况。但 “hit 高 ≠ 快” 是典型误区。
-
shared hit高说明数据在 shared_buffers 内，但若命中的是冷数据（刚被刷入 buffer 但尚未被预热），仍需等待 I/O 完成初始化 - 更关键的是看
read和write：哪怕hit=99%，只要某次write=1200（例如大排序落盘），就会拖慢整体响应 - 注意
local和tempbuffers：临时表或 CTE 物化会走temp，其性能受temp_buffers设置限制，和 shared_buffers 无关
Parallel Aware 开启了，为什么没真正并行？
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）
执行计划不是静态快照，每个字段背后都连着配置、统计、硬件和查询结构四层变量。调优时盯着单个值容易误判，真正要对齐的是「估算逻辑」和「运行时行为」之间的断层。
