Question

通常在改进查询时，在查询前后都运行cost时，actual time和explain 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中。

说明分析-成本与实际时间的关系

1 个答案: