为什么这个 WHERE 子句会扼杀查询性能？答案

【问题标题】：Why is this WHERE clause killing query performance?为什么这个 WHERE 子句会扼杀查询性能？
【发布时间】：2019-05-27 13:53:31
【问题描述】：

我有一个外部查询总结了三个 DB2 数据库的结果，这些数据库位于 AS400 上。内部联合查询运行大约 2 分钟。当我添加外部摘要查询时，性能不受影响。但是，将 WHERE 子句添加到外部摘要步骤会将性能提高到 10 分钟以上。因为我无法理解发生了什么，所以我每次都终止了查询。知道为什么添加 WHERE 子句会极大地影响性能吗？整个查询是这样的（抱歉伪代码，实际查询超过700行）：

SELECT
   field1,
   field2,
   SUM(field3) as my_sum
FROM
   (complex set of three queries with results unioned together from three different databases - runs in about 2 minutes when executed on its own)
WHERE field1 in('string1','string2','string3')
GROUP BY
   field1,
   field2

【问题讨论】：

操作系统版本？ AS400（DB2 for i）有两个优化器（CQE 和 SQE）。与 CQE 相比，SQE 更有效。 SQL 中的微小更改可能会将执行从 SQE 切换到 CQE。与新版本相比，旧版本的操作系统在更多条件下使用 CQE。

标签： sql db2

【解决方案1】：

为什么WHERE 子句会扼杀性能？

因为它改变了执行计划。您需要查看查询的解释计划。

为什么会改变执行计划？因为数据库认为（在这种情况下是错误的）附加过滤可以使替代执行计划更好。

你能做什么？提示是解决此问题以获得更优化计划的一种方法。

【讨论】：

感谢您的回复。不幸的是，我无权运行解释。我只需要尝试像优化器一样思考，或者找到重写的方法。
很可能 field_1 没有被索引，所以添加 where 语句会导致 RBAR，对吧？您可以在联合之前使用每个数据库上的索引过滤字段吗？
Field1 绝对不是索引，因为它是子查询中 CASE 语句的结果。 CASE 语句很长，这就是为什么我想避免在一个级别上实现它。
@timlash 你试过跑步和解释吗？还是你假设你没有权限？因为我不知道是否有可能专门撤销对它的访问。请注意，IBM i 世界中的“解释计划”是通过使用 Access Client Solutions (ACS) 或较旧的 iNav 的“运行 SQL 脚本”组件来调用的。有一个按钮“运行和解释”或只是“解释”，将在“视觉解释”中显示计划
您可以使用其他方式来理解优化器，例如 STRDBMON（您也将获得权限，但组织中的某个人应该有权执行 STRDBMON）。