使用oracle分析函数时是否有人遇到过慢的性能？ lead（）oracle分析函数用于在表中生成新字段。基本上，它允许将前一行的字段值用作当前行的新字段的值。解释计划表示在使用oracle分析函数的表上执行全表扫描。
为了避免这种全表扫描的成本，我可能只需使用后插入/更新触发器手动填充具有前一行值的具体字段
有人因为成本高而决定不使用oracle分析功能吗？是否应该很少使用oracle分析函数？
答案 0 :(得分：6)
分析功能并非没有成本：它们必须存储需要内存的中间结果（运行总计，窗口函数......）的数据，并且它们还需要一些处理能力。某些函数需要到结果集的最后一行才能返回结果（例如MIN / MAX）。大多数函数也会有一个隐式的SORT操作。
因此它们在资源方面不是免费的，但它们是SET操作，因此大多数时候它们比编写自定义的逐行plsql过程或传统SQL更有效。
您必须在特定情况下进行比较和基准测试，但如果您明智地使用它们，您会发现它们是强大的性能工具，而不是障碍。
答案 1 :(得分：3)
有关这方面的一些细节可以在Jonathan Lewis的博客here上找到。
真正的问题应该是，它们是否比替代品更高或更低，并且这将归结为特定情况。在某些情况下，您可能更愿意将数据提取到应用服务器并在那里进行处理，因为通常更便宜/更容易在该级别拥有额外的硬件。
但是在SQL中执行它并添加PL / SQL处理之间做出选择，我通常会使用SQL。
答案 2 :(得分：2)
这取决于您的表的索引方式以及您使用的功能。
例如， ROW_NUMBER()似乎效率低于ROWNUM，即使使用索引也是如此。请参阅我的博客中有关性能比较的文章：
Oracle的优化器知道窗口函数，并且可以使用STOPKEY和PUSHED RANK这样的一些技巧来提高它们的效率。
解释计划表明在使用oracle分析函数的表上执行了全表扫描。
表扫描本身并不错。如果检索索引中缺少的值的TABLE ACCESS比过滤和排序更昂贵，那么这可能是最佳的。
通常，如果对表进行索引，则查询WHERE和ORDER BY子句允许使用此索引进行排序，优化程序会认为此索引值得使用，WINDOW BUFFER方法用于{ {1}}和LAG函数。
引擎只保留LEAD行的运行缓冲区（或更多，取决于偏移量的值），并返回第一行和第二行的值。
但是，优化器可以认为该索引根本不值得使用。
在这种情况下，它将使用2：同样的事情，但排序是在内存或临时表空间中完成的。
答案 3 :(得分：1)
当然，他们有成本，你必须决定你是否能够支付。
在我的例子中，我创建了一个存储过程，它使用Oracle lead（）函数迭代表并计算一些日期，并将结果存储在另一个表中。最后，我在我的应用程序中使用此后续表，并每周更新第一个表（运行存储过程），因为该数据不会经常更改。
对我来说，这是最好的解决方案。