Performance 视图性能和正交性

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

<> P>我还能考虑什么来提高性能？ 我一直在这里寻找一些问题，ppl正在谈论正交，我不明白。 在这个链接中，有一个来自用户jjanes的答案，他在这里谈到了正交，但还不是很清楚。有人知道并能向我解释“正交”概念是如何与连接和子查询联系在一起的吗？

（这只是概念科目，但我使用postgre）

---

谢谢

好的，下面是在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;

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

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

---

希望这能有所帮助。

文章中的“正交”表示“与成直角”或“与功能无关”。这不是一项技术。我之前做过一些测试，这种行为变得很清楚，结果中的每一行也调用一次函数，这只是任何查询的性能杀手。我的结果很好，现在我将继续采用这种方法。让我恼火的一件事是，要修复一个视图，我必须修复四个或五个基本视图，以及更多的四个或五个基本函数。。我的数据库看起来像是一个面向对象的源代码。感谢您的帮助，我将在下一次重构中使用这一点。如果您忘记了面向对象的形式，那么面向对象的原则对于数据库来说是出人意料的适用。它们的应用非常不同。在理想形态中存在着惊人数量的差异。例如，对于过程代码，函数的调试复杂性为O（n），而对于SQL，它更像O（log（n）），前提是您可以保持SQL非常好的结构（显式连接、避免子查询或内联视图等）。因此，Python或C中的函数的最大调试大小约为20-30行，但对于SQL，一个200行的查询很可能会分解成相当明显的20-40行块进行调试，其中最大、最复杂的块是join块。所以不要害怕很长的问题。