sql - FORALL 与 FOR 批量更新

Question

这是在采访中被问到的。问题是，哪个更快，在 5000 条上使用 FORALL 还是在 500 条记录上使用 FOR？
好吧，我认为就处理速度而言，FORALL 确实更快，但仍然取决于要处理的行数，就像上述问题一样。
请分享您的想法。

Answer 1

这取决于。

首先，测试是如何设置的？在普通代码中，您的 for 循环运行查询并执行某些操作，因此，如果您要测量循环的性能，则将运行查询、获取结果和对结果执行某些操作所需的时间组合在一起。

for x in (<<some select statement>>)
loop
  <<do something with x>>
end loop;

另一方面， forall 意味着您已经完成了将需要处理的数据提取到本地集合中的工作。

forall i in 1..l_collection.count
  <<do something>>

包括在一种情况下运行查询和获取结果所需的时间并从另一种情况中排除该时间的性能比较是不公平的比较。您要么需要在 forall 案例中包含填充集合的成本，要么需要 for 循环来迭代已填充的集合，以便比较公平。您使用哪种方法可能会对结果产生巨大影响。
forall 消除了 SQL 和 PL/SQL 引擎之间的上下文转换，就是这样。如果程序运行时的很大一部分用于上下文转换，这将非常有用。你对数据做的事情越昂贵(如果你包括那个时间，获取数据的成本就越高)，花在上下文转换上的时间比例必须越小。如果您不包括获取数据所需的时间并且循环的内容是微不足道的操作，那么 for 循环解决方案很可能会花费 90% 以上的时间进行上下文转换，因此 forall 解决方案可能快 10 倍.如果您将获取数据所需的时间包括在内，那么该时间是整个运行时间的很大一部分，并且循环的内部是一项昂贵的操作，那么 for 循环解决方案可能会花费一小部分时间来处理上下文转变，因此使用 forall 不会使您获得近 10 倍的改进。

如果将填充集合所需的时间包括在内，事情会变得更加复杂，因为有多种可能的编写方式会具有不同的性能特征，具体取决于您使用的是隐式游标还是显式游标以及 Oracle 版本。这是 this question on the performance of a bulk collect 中更详细讨论的内容。