类似 Oracle 函数集的优化选项答案

【问题标题】：Optimisation Options for Set of Similar Oracle Functions类似 Oracle 函数集的优化选项
【发布时间】：2011-08-10 11:29:58
【问题描述】：

我有三个自定义函数，它们做的事情非常相似：它们从同一组相当复杂的连接中提取不同的数据——生成连接表需要时间——并且通常都在同一个 @987654321 中调用@。这显然效率低下，我想提高性能，但最好的方法是什么？

对于像我这样的菜鸟来说，第一个选项可能是最好的解决方案；但它显然有创建一个相当大的物化视图的缺点，这需要维护（因此它会根据需要刷新）；虽然这个 MV 可能在其他地方有用……第二个选项有点小技巧；但还有什么我没有考虑到的吗？

【问题讨论】：

n.b.，它必须是物化视图；如果它是一个常规视图，它会（大概）在每次需要时执行，这是同样的问题。
你能发一个这些函数的例子吗？
@Tony：我不确定公开我的功能是否很酷；但是胆量涉及一个大的select，这是相当简单的保存with 块，这是低效率的根源。鉴于with 部分非常透明，它非常适合移动到 MV 中。

【解决方案1】：

我宁愿完全省略函数并重新编写查询以便不使用函数。任何选择数据的函数（尤其是使用“复杂连接”）都是减慢查询速度的可靠方法，因为该函数必须对主查询处理的每一行（甚至不一定返回）执行一次，可能是 1000 秒（或100,000 次）次。

【讨论】：

确实...我的项目是创建一个抽象层，因为所需的查询对于其他人来说太复杂了（例如，在报告中）。函数似乎是最好的解决方案；尽管在这种情况下，性能会有所妥协。
使用视图隐藏复杂性怎么样？
我想这很大程度上是出于一致性。我在任何地方都使用过函数——大多数时候，不存在这种问题——以免除最终用户对模式的了解（即，需要编写连接，即使使用视图来简化事情）。跨度>
我明白了。好吧，SQL 并不是真正为最终用户设计的：他们更喜欢你点击的东西！

【解决方案2】：

老实说，我会选择选项 2，除非您真的想要物化视图。您可以将函数转换为表格，以便正常从中进行选择。

【讨论】：

这是我要选择的选项，因为物化视图将有效地总结数据库中最大的表（大约 0.5GB 大小），以及可能是第二大的表......不要这样做！
...将三个函数合并为一个函数将查询的运行时间从 17 秒减少到 6 秒。耶:)
虽然它确实显示了这些函数调用有多慢。我们假设线性——这不是一个好的假设，但没关系——然后，假设基本查询（也称为函数）在时间 x 中运行，而这个函数在 y：x + y = 6 和 x + 3 y = 17；因此基本查询在 0.5 秒内运行，而函数需要 5.5 秒来执行（即长一个数量级）：P