sql - 使用 DB2 查询怪癖，无操作合并将运行时间减半

Question

我正在优化 DB2 数据库的一些查询。它们中的大多数都运行良好，但有一些返回的数据集相当大(最多 30k 行左右)给我带来了一些麻烦。这些查询没有什么特别复杂的。他们从多达十几个连接中选择了大约 15 个不同的列，其中有一些内部连接和左连接。有一些 IN 子句使用参数和子查询来减少数据集。没什么特别的。

我一直在查看一些索引，但运气不佳。问题是，在试图强制使用未被利用的新索引时，我偶然发现了 DB2 中的一个巧妙技巧:谓词中的无操作 COALESCE 可能会降低成本和运行时间。

基本上，它是这样工作的:

SELECT ...
FROM A
JOIN B
ON A.ID1 = B.ID1
AND A.ID2 = B.ID2
--More inner and left joins--
WHERE
B.TYPE_CODE IN (:parameter)
AND A.X IN (--subquery--)
AND
COALESCE(B.TYPE_CODE,B.TYPE_CODE) = B.TYPE_CODE

从逻辑的角度来看，COALESCE 什么都不做，B.TYPE_CODE 永远不会为空。然而，这会诱使 DB2 优化器估计较少的行数，此处解释:

http://www-01.ibm.com/support/docview.wss?uid=swg21259831

对于 TABLE B，TYPE_CODE 列有大约 15 个不同的可能值，并且分布不均匀。那里大约有 270 万行，A 中大约有 90 万行。因此，B 中的 ID1/ID2 列可能重复相同的值对最多 15 次或只出现一次。 :参数不超过四个值。

奇怪的是 COALESCE 语句将查询时间减少了一半。在检查解释计划时，我注意到 A 上的几个表扫描变成了索引扫描，这可能是由于返回行的较低估计使得索引扫描对优化器可行。我一直在四处寻找并试图找到一个可能的原因。 RUNSTATS 最近在这些表上运行，SYSCAT.COLDIST 表中有一些非常新的数据，如果我手动检查计数，至少在值的 1% 以内。我注意到它并没有包含 TYPE_CODE 列中的所有值，但是丢失的值很少出现，并且从 IN 子句中省略稀有值对查询时间没有实际影响。我已经在其他列上尝试过 COALESCE，但从未有过相同的效果。

我能想到的唯一解释是一些统计数据陈旧、糟糕、过时等等，但如果我知道在这一点上看哪里，那就太糟糕了。我可以说没有适当的列组统计信息，但我的知识不足以说明这是否会有所作为。

我不想将 COALESCE 声明投入生产，因为它有点老套，更像是解决更深层次问题的创可贴，而不是解决方案本身。在我看来，DB2 高估了该连接中将返回的行数，但如果我知道原因，那就太糟糕了。我希望其他一些具有 DB2 经验的人能够对此有所启发。

Answer 1

我想知道为什么你有 in (:parameter)，parameter 不是单个值吗？

与 IN 相比，您从单独的 OR 子句中获得更好的性能吗？

我的目标是 IN 子句，因为它显然会带来性能问题(请参阅:Performance of "in" condition query in db2)。