时间戳

首页 > 解决方案 > 了解 SQL 查询复杂性

postgresql - 了解 SQL 查询复杂性

问题描述

我目前无法理解为什么一个看似简单的查询比一个更复杂（看起来）的查询需要更长的时间才能返回结果。

我有一个视图，performance_summary（它又从另一个视图中选择）。目前，在 内psql，当我运行类似的查询时

SELECT section 
FROM performance_summary 
LIMIT 1;

返回结果需要一分钟左右，而像

SELECT section, version, weighted_approval_rate 
FROM performance_summary 
WHERE version in ('1.3.10', '1.3.11') AND section ~~ '%WEST' 
ORDER BY 1,2;

几乎立即得到结果。在不知道视图是如何定义的情况下，是否有任何明显或常见的原因？

标签： postgresql

解决方案

不是真的，不知道视图是如何定义的。可能是“更复杂”的查询使用索引仅选择两行，然后对这两行执行一些简单的分组排序。没有 where 子句的查询可能会看到 postgres 在数百万行上运行，数万亿次操作并在丢弃 999999999 行后产生单行，除非您发布两个查询的视图定义和解释计划输出，否则我们不知道

您可能会陷入认为 View 在某种程度上是信息缓存的陷阱 - 它不是。这是一个存储查询，当您从中选择/包含在另一个查询中时，它会插入到更大的查询中——这意味着必须从头开始计划和执行整个事情。没有一个概念是创建一个视图会做任何预先计划等，在此基础上进行其他进一步的改进。这更像是视图的定义被粘贴到任何使用它的查询中，然后查询运行就像它只是写在那里一样，然后

推荐阅读