db2 中“in”条件查询的性能答案

【问题标题】：Performance of "in" condition query in db2db2 中“in”条件查询的性能
【发布时间】：2025-12-10 15:20:02
【问题描述】：

我想从 DB2 数据库中的表中获取以下数据。

select col1, col2, col3 from employee where employee_id in (1,2,3)

请分享您对查询性能的看法？有其他选择吗？

【问题讨论】：

你的桌子上有什么索引？我从未使用过 db2，但一个明显的替代方法是范围搜索 where employee_id >= 1 and employee_id <= 3
如果employee_id上有合适的索引，绝对没问题
只要in 子句的值部分不是不相关的子选择。在这种情况下，iSeries 上的 DB2 对性能有一些影响（范围选择或实际的 join 往往性能更好）
@afuzzyllama - 不了解 db2，但在 SQL Server 中，第二个会有一点好处。 IN 将是 3 次索引搜索，这意味着索引从根导航到叶 3 次。 BETWEEN 将是一个单一的索引导航。这在sqlblog.com/blogs/paul_white/archive/2011/02/16/… 中得到了很好的介绍。据我所知，db2 可能会做一些完全不同的事情。
@Martin Smith - 我在 iSeries 上使用 DB2，它是一个不同的野兽......让我告诉你

【解决方案1】：

传统上，DB2 对 IN 谓词的优化很容易估计结果集的基数错误。使用 IN 谓词，它有时可能会针对超出常识的结果进行优化。

它的工作原理与上面的 Martin Smith 所写的完全一样——按顺序运行 3 个单独的索引查询。这可以通过启用优化来修复

db2set DB2_INLIST_TO_NLJN=true

这迫使 DB2 创建一个临时虚拟表并执行嵌套循环连接（在许多情况下是一个非常好的选项）或通过切换到不同类型的查询，例如范围版本。您还可以推动 DB2 使用嵌套循环连接版本，例如

select col1, col2, col3 
from employee, (values 1,2,3) as v(ids) 
where employee_id=v.ids

请记住，这一切都有些学术性，除非您的 IN 查询中有大量项目并且目标表中有行，并且必须运行大量此类查询。

【讨论】：