真正有用的是actual total time、buffers（shared hit/read/dirty/write）和wal records；analyze触发真实执行与锁表，buffers反映缓存效率，settings显示会话级关键参数，wal仅对写操作有效。
EXPLAIN (ANALYZE, BUFFERS, SETTINGS, WAL) 里哪些字段真有用
不是所有输出都值得盯——ANALYZE 启动实际执行，BUFFERS 暴露缓存命中/刷盘行为，SETTINGS 锁定会话级配置（比如 work_mem 或 enable_hashjoin），WAL 则只在写操作中显示生成的 WAL 记录数。四者叠加后，真正影响判断的只有三类数据：Actual Total Time（真实耗时）、Buffers: shared hit/read/dirty/write（缓存层效率）、WAL records（写放大程度）。
常见错误是盯着 Plan Rows 和 Actual Rows 的偏差猛看，却忽略 Buffers: shared read=1234 这种信号——它直接说明磁盘 IO 是否失控。如果 read 值远高于 hit，哪怕总时间不长，也意味着查询无法复用缓存，下次可能更慢。
-
SETTINGS输出里重点核对search_path和default_statistics_target，它们会悄悄改变计划选择 -
WAL字段只在INSERT/UPDATE/DELETE中出现，SELECT执行时为空，别误以为漏了 - 若
Actual Total Time明显大于各子节点Actual Total Time之和，说明有隐式锁等待或后台进程干扰（比如 autovacuum 抢资源）
为什么 ANALYZE 一开，查询就变慢还卡住
因为 ANALYZE 不仅执行计划，还会强制等所有操作完成、收集完整运行时统计，并阻塞其他并发修改（尤其在大表上）。它不是“只读快照”，而是真实跑一遍，期间锁住目标表的 AccessShareLock，同时触发 shared_buffers 刷脏页、可能引发 checkpoint。
典型表现：执行 EXPLAIN (ANALYZE) SELECT * FROM huge_table LIMIT 1 却卡住十几秒——问题不在 SQL，而在 PostgreSQL 正在把几 GB 的数据从 shared_buffers 刷到磁盘，或被另一个 VACUUM 持有 AccessExclusiveLock。
- 避免在业务高峰跑带
ANALYZE的EXPLAIN，尤其涉及大表或写操作 - 加
VERBOSE参数不会加重开销，但加WAL对写操作会多记日志，进一步拖慢速度 - 如只需估算，用
EXPLAIN（无ANALYZE）+pg_stat_statements查历史平均耗时更安全
Buffers 输出里 hit/read/dirty/write 怎么对应到物理行为
Buffers: shared hit=1234 read=567 dirty=89 write=45 这串数字不是并列关系，而是分阶段反映内存与磁盘交互：
hit 是从 shared_buffers 直接读到的数据页；read 是从磁盘加载进缓冲区的页数；dirty 是本次查询导致缓冲区中页被标记为“需刷盘”（比如 UPDATE 修改了页）；write 是实际同步写入磁盘的页数（受 bgwriter 和 checkpoint 控制，不一定等于 dirty）。
- 高
read+ 低hit→ 缓冲区太小或数据局部性差，考虑调大shared_buffers或优化查询范围 - 高
dirty+ 极低write→ 写压力被后台写进程承接，但若后续 checkpoint 频繁，可能引发 IO 尖峰 -
local和tempbuffers 只在使用临时表或 CTE 物化时出现，普通查询看不到
SETTINGS 输出中哪些配置项会偷偷改执行计划
SETTINGS 显示的是当前会话生效的参数，其中几个对计划影响最直接：enable_seqscan、enable_indexscan、random_page_cost、effective_cache_size、work_mem。它们不报错也不警告，但能让你的索引突然“失效”或让哈希连接变成嵌套循环。
例如，effective_cache_size = '4GB' 而实际可用内存只有 2GB，优化器会高估缓存能力，倾向选择顺序扫描而非索引——因为预估“随机读很快”。又比如 work_mem = '4MB'，而排序需要 10MB，就会退化成外排（disk-based sort），EXPLAIN 中会出现 Sort Method: external merge。
- 检查
random_page_cost是否仍设为默认 4.0：SSD 上应降到 1.0–1.3，否则索引扫描永远比不过顺序扫描 -
jit相关参数（如jit_above_cost）开启后，可能引入 JIT 编译延迟，ANALYZE时间会包含这部分，但Plan部分不体现 - 用
SHOW ALL看全局值，但EXPLAIN (SETTINGS)显示的是当前事务内SET LOCAL覆盖后的值，别混淆
真正难缠的是那些不写进 SETTINGS 却影响行为的隐式因素：表膨胀率（pg_class.reltuples vs 实际行数）、统计信息陈旧度、分区键绑定是否严格。这些没法靠一次 EXPLAIN 捕获，得配合 pg_stats 和 pg_class 交叉验证。
