解释分析-成本与实际时间的关系

Question

通常，在改进我的查询时，我会发现在查询之前和之后都运行时，cost两者都有一致的改进。actual timeexplain analyze

然而，在一种情况下，之前的查询报告

"Hash Join  (cost=134.06..1333.57 rows=231 width=70) 
            (actual time=115.349..115.650 rows=231 loops=1)"
<cut...>
"Planning time: 4.060 ms"
"Execution time: 115.787 ms"

以及之后的报道

"Hash Join  (cost=4.63..1202.61 rows=77 width=70) 
            (actual time=0.249..0.481 rows=231 loops=1)"
<cut...>
"Planning time: 2.079 ms"
"Execution time: 0.556 ms"

正如您所看到的，成本相似，但实际执行时间和实际执行时间却截然不同，无论我运行测试的顺序如何。

使用 Postgres 8.4。

谁能澄清我对为什么成本没有改善的理解？

Answer 1

问题中给出的详细信息中没有太多可用信息，但一些提示可能会帮助来这里搜索该主题的其他人。

• 成本是基于对查询涉及的表运行分析时计算的表统计信息的数值估计。如果从未分析过该表，那么该计划和成本可能不是最佳的。查询计划受表统计信息的影响。
• 实际时间是运行查询所花费的实际时间。同样，这可能与成本没有正确关联，具体取决于表统计信息的新鲜程度。计划可能会根据当前表统计信息得出，但实际执行时可能会发现实际数据情况与表统计信息不同，从而导致执行时间出现偏差。

这里需要注意的是，表统计影响计划和成本估算，而计划和实际数据情况影响实际时间。因此，作为最佳实践，在进行查询优化之前，始终对表运行分析。

一些注意事项：

• analyze <table>- 更新表的统计信息。
• vacuum analyze <table>- 从表中删除已更新记录的陈旧版本，然后更新表的统计信息。
• explain <query>- 仅使用查询中涉及的表的统计信息生成查询计划。
• explain (analyze) <query>- 使用查询中涉及的表的现有统计信息生成查询计划，并运行查询收集实际运行时数据。由于查询是实际运行的，如果查询是 DML 查询，那么如果不打算持久化更改，则应注意将其包含在 begin 和 rollback 中。