使用Postgres EXPLAIN ANALYZE时，优先参考cost还是actual time？

• 沙箱与生产环境的差异是核心变量：你的沙箱数据集更小、模式不同，这直接导致沙箱里的执行计划和实际性能完全不具备生产环境的参考性。PostgreSQL的执行计划选择高度依赖统计信息——哪怕跑了ANALYZE，小数据集的字段值分布和生产环境的大数据集天差地别，比如ut.person_id IS NULL的记录占比，沙箱和生产可能完全不一样，这会让数据库选择完全不同的扫描方式（比如索引扫描vs全表扫描）。

• cost值与实际执行时间脱节的原因：cost是数据库基于统计信息算出的估算值，单位是“磁盘页面读取成本”，并非实际运行时间。你看到cost下降，可能是数据库认为ut.person_id IS NULL的过滤条件能更快缩小结果集，但沙箱里实际这个条件的过滤效率反而更低（比如沙箱里person_id IS NULL的记录更多，或者没有对应的索引），导致实际执行时间上升。但生产环境如果有合适的索引，或者该条件的过滤率更高，结果可能完全相反。

• 无法直接预判生产性能，必须做这几步验证：

  1. 在生产环境的只读副本上（避免影响业务），分别执行原查询和修改后查询的EXPLAIN ANALYZE，对比实际执行时间和执行计划。
  2. 检查生产环境中ut.person_id字段是否有合适的索引——如果这个IS NULL过滤是常用场景，可以建部分索引：CREATE INDEX idx_ut_person_id_null ON ut (id) WHERE person_id IS NULL;。
  3. 先确认person IS NULL和ut.person_id IS NULL这两个条件的语义完全等价——如果业务逻辑不一致，性能对比毫无意义。

• 额外提醒：如果生产环境数据集很大，全表扫描的成本会急剧上升，此时如果修改后的条件能利用索引，性能可能大幅提升；反之，如果修改后的条件让数据库选择了低效的执行计划（比如嵌套循环而非哈希连接），性能可能更差。只有在生产环境（或完全镜像的测试环境）实际测试，才能得到准确结论。

内容的提问来源于stack exchange，提问作者Christian Bueche