程序员：使用 DB2 for z/OS 减少会话：第 1 部分：Prem Mehra 说过：“没有比不执行的 SQL 性能更好的 SQL 了。”

核心提示： 但是，读取并计入行，程序员：使用 DB2 for z/OS 减少会话：第 1 部分：Prem Mehra 说过：“没有比不执行的 SQL 性能更好的 SQL 了。”(3)，然后再读取行并处理它是不能解决问题的，不建议执行两次读取，下一期将提供更多无用 SQL 的例子，并提供一些更加优秀的替换代码

但是，读取并计入行，然后再读取行并处理它是不能解决问题的。不建议执行两次读取，即使分页已经在缓冲池中。我不知道是多少次听到这种方法了？只是因为，分页可以在缓冲池中并不意外着可以随意执行第二次读取。由于 DB2 是一台重要、动态的维护机器，因此消除连接是一种可显著降低 CPU 和 GET PAGE 开销的方法。

那么，针对这个问题有什么更好的方法呢？程序员都在避免较高开销的指针。因此，可以考虑一下这个问题：经常会遇到只有一个行的情况吗？你说有百分之九十八的机率？那就先执行单体 SELECT。然后，如果接收到一条 -811 ("multiple rows returned to a Singleton Select") 错误消息，则打开指针。如果大多数时间都可以找到多个行，则立即打开指针，而不用担心来自单体 SELECT 的反馈。换句话说，首先采用常普遍的方式，如果不行再执行 COUNT。

COUNT(*)：问题 3

我们再看另一个实际生活中的例子：

此 COUNT 采用的逻辑如下：将 :hvcount 除以 10（屏幕上可显示的行数），计算数据需要占用多少个屏幕。为什么呢？这样，每个屏幕（包括初始屏幕在内）都可以为用户显示 "Page 1 of n"。此处，我们可能会遇到 “不能删除” 的情况。但是，如果用户点击 PF8 直到没有行 / 屏幕时，是否可以采用更好的方式来确定有多少个 10 行的屏幕呢？

是的，首先应该问：“通常有多少个屏幕？”如果回答是一个屏幕或多个屏幕，则在阅读之前不应计入这些行数。相反，打开指针，获取行并在阅读时计入这些行。如果在点击第 11 行时到达 End of File，那么应该可以知道答案，而不用执行 COUNT。并且，您已经删除了 DB2 在执行 COUNT 时引入的所有 GET PAGE（或许是 READ I/Os）。

如果行数通常介于 11 和 30 呢？也应该读取这些行，并在执行 FETCH 时计入它们。如果在读取到第 31 行时计数已经达到 +100，则将这些行保存在屏幕显示中间的某个位置（比如说 CICS 的 COMMAREA）。在第一页上添加 "Page 1 of 3"，然后删除 PF8 显示 "Page 2 of 3" 和 "Page 3 of 3" 所需的指令。

如果有 3 个以上页面，则将用户实际看到的内容保存在 COMMAREA 中（或任意位置）。然后，执行 COUNT。您已经将 COUNT 延缓到了最迟执行。您已经避免了大多数情况下的两次读取操作。最为重要的是，您的程序已经具备了良好的逻辑，其他人采用相同的方式编写自己的程序。

结束语

对于日常需要使用 DB2 的用户，以及对我的示例非常了解的用户，我感觉感谢你们的支持和帮助，感谢你们分享了自己的思想和智慧。对于其他用户，下一期将提供更多无用 SQL 的例子，并提供一些更加优秀的替换代码的解决方案。敬请期待第 2 部分。