0

我正在尝试为我的一些工作升级许多视图性能,我现在正在做一些事情,比如删除子查询、调用 select 中的其他函数(在其中进行选择的函数),以及通过 Join 进行操作。我想知道它是否是正确的选择,即使我认为我在没有过滤器的情况下检索视图会得到更好的结果(比如说 20000 行),但它是否会给我带来更好的结果还不是很清楚,比如说, 200 行。你如何面对这种你有很多结果的观点,或者加入有点贵?

我还能考虑什么来提高性能?

我一直在这里寻找一些问题,而 ppl 正在谈论正交,我不明白。在这个链接中有一个来自用户 jjanes 的答案,他谈到正交,但不是很清楚。有人知道并可以向我解释如何使用联接和子查询来考虑“正交”概念? View 不会提高相关子查询的性能?

(这只是概念主题,但我使用 postgre)

谢谢

4

1 回答 1

1

好的,这是在 PostgreSQL 中优化视图(和其他长查询)的基本指南。

首先要了解计划者拥有的信息越多越好。对函数的调用有时是不可避免的,但您必须了解它们通常是规划器不透明的,这实际上意味着规划器无法将逻辑折叠到主查询中,并且必须单独运行查询。所以删除函数是一个很好的第一步(除非你的视图只是包装一个函数,在这种情况下这样做没有任何好处)。

第二件要理解的事情是视图封装了数据逻辑,虽然这看起来是件好事,但它有很多很多的陷阱。在这方面,SQL 编程与良好的面向对象设计正好相反,部分是因为 SQL 是声明性的,部分是因为它是严格组织的(使得调试更长的语句比调试 Python 中相当长的函数更容易) )。所以要做的一件事是删除针对其他视图中的视图的连接。

例如,想象一下,如果我有一个视图,比如说,joins(这并不过分,真的)。但随后我使用自联接对视图运行查询。现在我已经从 9 个连接变成了 81 个,从查看导致问题的查询来看问题并不明显(但是男孩,看看查询计划!)。

一般来说,您的最佳视图将是以下三种之一:

  1. 简单的函数包装器。例如:

    CREATE VIEW current_stock_list AS select * from parts_stock_list(now());
    
  2. 其他表或视图的简单子集(但不是视图包装函数),例如:

    CREATE VIEW warehouse_current_stock AS select * onhand_stock WHERE warehouse = 1;
    
  3. 访问基础表的大型复杂查询。如果您避免在流程中加入视图和函数,则 100 行查询将优于 10 行查询。

希望这可以帮助。

于 2013-12-13T02:25:18.447 回答