Question

我正在尝试升级我的一些工作的许多视图性能，我现在正在做的事情就像删除subquerys，调用select中的其他函数（在其中进行选择的函数），以及通过Join来制作东西。我想知道它是否是正确的选择，甚至认为我获得更好的结果来检索没有过滤器的视图（比方说20000行），它不是很清楚它会给我一个更好的结果，比方说， 200行。你如何面对这种观点，你有很多结果，或者加入那么贵？

我还可以考虑提高性能吗？

我一直在寻找一些问题，ppl正在谈论正交，我不明白。在这个链接中有一个来自用户jjanes的答案，他谈到正交，但不是那么清楚。有人知道并且可以向我解释如何用Joins和Subquerys来思考“正交”概念？ View doesn't increase performance of correlated subquery?

（这只是概念主题，但我使用postgre）

由于

Answer 1

好的，这里是优化PostgreSQL中的视图（和其他长查询）的基本指南。

首先要了解规划师拥有的信息越多越好。调用函数有时是不可避免的，但您必须了解它们通常是规划器不透明的，这有效地意味着规划器无法将逻辑折叠到主查询中，并且必须单独运行查询。因此删除函数是一个很好的第一步（除非你的视图只包含一个函数，在这种情况下，这样做没有任何好处。）

要理解的第二件事是视图封装了数据逻辑，虽然这似乎是一件好事，但它有很多很多陷阱。在这方面，SQL编程与良好的面向对象设计正好相反，部分原因是SQL是声明性的，部分是因为它是严格组织的（比如Python中相对长的函数调用更长的语句更容易））。因此，要做的一件事是删除其他视图中的视图的连接。

想象一下，例如，如果我有一个视图，比如连接（实际上并不过分）。但后来我使用自联接对视图运行查询。现在我已经从9个连接变为81个，并且通过查看导致问题的查询问题并不明显（但是男孩，请查看查询计划！）。

一般来说，您最好的观点将是以下三种之一：

简单的函数包装器。例如：

CREATE VIEW current_stock_list AS select * from parts_stock_list(now());

其他表或视图的简单子集（但不包括视图包装函数），例如：

CREATE VIEW warehouse_current_stock AS select * onhand_stock WHERE warehouse = 1;

大型复杂查询命中基础表。如果您避免加入过程中的视图和函数，则100行查询将优于10行查询。

希望这有帮助。

查看性能和正交

1 个答案: