调优 SQL 过程

核心提示： 调优存在谓词我无法理解开发人员为何用下方所示方式编写存在检查（existential check），但是因为他们这样做了，调优 SQL 过程(6)，所以我们就来讨论它，优秀的开发人员有时候似乎害怕执行那些可能导致 NOT FOUND 警告的语句，处理该逻辑的过程有一个最外层的检查，决定是执

调优存在谓词

我无法理解开发人员为何用下方所示方式编写存在检查（existential check），但是因为他们这样做了，所以我们就来讨论它。

优秀的开发人员有时候似乎害怕执行那些可能导致 NOT FOUND 警告的语句。下面的例子是一条模仿 MERGE 的语句。

这两个存在检查为何不好？

首先，要求 DB2 回答一个不相关的问题。仅仅为了检查某些行是否存在而迫使 DB2 计算一个表中的行数是一种代价极其高昂的选择。

其次，除非某一个表使用语句级触发器，否则，用显式查询来检查某一行是否存在的代价就与未找到要更新的行就执行 update 语句的代价一样高。在该行没有被查找到的情况下，这两种方式没有什么区别。但是如果已经通过 EXIST 谓词找到了这个行，那么 UPDATE 还是必须再次查找它。

因此，如果没有更多注释，这里有一种更好的方法，可用这种方法来处理通常用来处理条件更新和执行存在检查的显式方式。

当然，可以总是对单行使用显式 EXISTS 谓词和 MERGE 语句，两者将获得相似的性能。

CALL 回避

有许多种在紧凑循环（tight loop）中调用过程的情况。使用队列或关系中间表（staging table）的批处理过程就是一个例子。队列中的每个对象如果满足指定条件，就可能触发特殊处理。对于任何给定对象，这些条件通常很少为真。因此，处理该逻辑的过程有一个最外层的检查，决定是执行主体的其余部分，还是不采取任何动作而返回。