Question

我有一个简单的选择查询：

SELECT * FROM entities WHERE entity_type_id = 1 ORDER BY entity_id

然后我想获得前100个结果，所以我用它：

SELECT * FROM entities WHERE entity_type_id = 1 ORDER BY entity_id LIMIT 100

问题是第二个查询的工作速度比第一个慢得多。执行第一个查询只需不到一秒钟，执行第二个查询需要一分钟以上。

这些是查询的执行计划：

无限制：

Sort  (cost=26201.43..26231.42 rows=11994 width=72)
  Sort Key: entity_id
  ->  Index Scan using entity_type_id_idx on entities  (cost=0.00..24895.34 rows=11994 width=72)
        Index Cond: (entity_type_id = 1)

有限制：

Limit  (cost=0.00..8134.39 rows=100 width=72)
  ->  Index Scan using xpkentities on entities  (cost=0.00..975638.85 rows=11994 width=72)
        Filter: (entity_type_id = 1)

我不明白为什么这两个计划如此不同以及为什么性能会下降太多。我应该如何调整第二个查询以使其更快地运行？

我使用PostgreSql 9.2。

Answer 1

您希望100个最小的entity_id匹配您的条件。现在 - 如果那些是数字1..100那么显然使用entity_id索引是处理这个的最好方法 - 一切都是预先排序的。事实上，如果您想要的100在1..200的范围内，那么它仍然有意义。可能1..1000会。

所以 - PostgreSQL认为它会在＆＃34; start＆＃34;中找到很多entity_type_id = 1的值。的表。它估计成本为8134对比26231按类型过滤然后排序。在你的情况下，这是错误的。

现在 - 要么有一些相关性并不明显（那很糟糕 - 我们现在无法告诉规划人员），或者我们没有 - 至今或足够的统计数据。

ANALYZE entities会有什么不同吗？您可以通过阅读planner-stats page in the manuals来了解规划师了解的值。

PostgreSql选择查询性能问题

1 个答案: