SQL EXPLAIN / EXPLAIN ANALYZE 的关键字段解读与 cost / actual time 对比分析

postgresql的explain中cost是优化器基于i/o和cpu的相对开销估算值，非实际时间；actual time才是真实毫秒耗时，含启动与总时间、行数及循环次数。

EXPLAIN 输出里 cost 是什么，为什么它不等于执行时间

PostgreSQL 的 EXPLAIN 中的 cost 是优化器估算的相对开销值，不是毫秒，也不是 CPU 时间。它基于磁盘 I/O（1.0 = 一次顺序页读取）和 CPU 操作（0.01 = 一次简单运算）建模，所有数值都按比例缩放，只用于比较不同执行计划的优劣。

• 实际执行时，cost 完全不反映并发、缓存命中率、磁盘延迟或网络传输——比如一个 cost=1000 的索引扫描，若数据全在 shared_buffers 里，可能比 cost=200 的磁盘排序快得多
• enable_seqscan=off 强制走索引，可能让 cost 翻倍但实际更快；反之，random_page_cost 设太高会让优化器回避真实高效的随机读
• 如果 EXPLAIN ANALYZE 显示 actual time 远高于 cost 对应的“理论值”，大概率是统计信息过期（ANALYZE 没跑）或 work_mem 不足导致落盘

EXPLAIN ANALYZE 的 actual time 字段怎么读，各阶段含义是什么

actual time 是真实耗时（单位毫秒），格式为 actual time=0.025..124.852 rows=1234 loops=1：前面是启动时间（从开始到返回第一行），后面是总时间（从开始到最后一行返回），rows 是该节点实际输出行数，loops 表示该节点被重复执行次数（常见于嵌套循环内层）。

• 注意 loops > 1 时，actual time 是单次耗时，不是总耗时；总耗时 ≈ (启动时间 + 总时间) × loops，但 PostgreSQL 不直接给出，得自己算
• 如果某节点 actual time 很大但 rows 很小，可能是 I/O 等待（如 Buffer read 高）、锁等待（Lock wait 出现在日志里），或函数调用（如 pg_sleep()）卡住
• Planning Time 和 Execution Time 在 EXPLAIN ANALYZE 结尾单独列出，前者高说明查询结构复杂或统计信息混乱，后者才是执行本身耗时

哪些 cost / actual time 差异说明优化方向明确

当 cost 和 actual time 出现系统性偏差，往往指向可落地的调优动作，而不是玄学猜测。

• Seq Scan 的 actual time 远低于 cost → 数据基本在内存，但优化器还按磁盘读估算，检查 effective_cache_size 是否设得太低
• Hash Join 节点 actual time 极高且 Hash table size 超出 work_mem → 必须调大 work_mem 或改写为 Merge Join（需有序）
• Index Scan 行数远少于 rows 估算值（比如估算 10000，实际 12），但 actual time 却很高 → 可能索引字段选择性差，或存在隐式类型转换（如 WHERE text_col = 123），触发全索引扫描

EXPLAIN ANALYZE 在生产环境怎么安全用，避免拖垮系统

EXPLAIN ANALYZE 会真实执行查询，对写操作、大表扫描、锁竞争场景有风险。不能直接在高峰期对 UPDATE 或 select for UPDATE 跑。

• 读查询加 LIMIT 10 再 EXPLAIN ANALYZE —— 但注意：加 LIMIT 可能改变执行计划（比如跳过排序），此时应配合 OFFSET 0 或用 pg_hint_plan 固定计划再测
• 想看执行过程但不想等完，用 EXPLAIN (ANALYZE, TIMING OFF, SUMMARY OFF) 关闭详细计时和汇总，减少开销
• 对疑似慢查询，先 EXPLAIN（不带 ANALYZE）看计划是否合理；只有计划没问题但实际慢，才上 EXPLAIN ANALYZE；如果计划就错（比如该走索引却走全表），优先查统计信息和条件写法

最常被忽略的是：cost 模型依赖的参数（random_page_cost、cpu_tuple_cost 等）和真实硬件脱节时，优化器永远“算不对”。调参不是玄学，但得从 EXPLAIN ANALYZE 里找证据——比如 SSD 服务器还用默认 random_page_cost=4.0，那 cost 就天然高估随机读 4 倍。