查看性能和正交

Question

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

我还可以考虑什么来提高性能？

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

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

谢谢

Answer 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 行查询更可取。

希望这会有所帮助。