DB2 12 for z/OS大表查询优化：创建索引能否提速？

核心结论：创建索引完全有效，是解决当前问题的最优方案 #

直接查询耗时55秒的本质是PERSONTABLE没有针对DNUM的索引，导致执行了全表扫描；而关联查询快，是因为OTHERTABLE大概率有DNUM的索引，能快速定位到PERSONCODE，再通过PERSONCODE关联（若PERSONTABLE有PERSONCODE索引），跳过了全表扫描。

具体优化方案 #

1. 创建覆盖索引（最推荐，无侵入性）

直接创建包含查询所需所有列的覆盖索引，DB2可以直接从索引中获取数据，无需回表查询原表，这是针对当前查询最快的优化方式：

CREATE INDEX IX_PERSON_DNUM_COVER ON PERSONTABLE (DNUM) INCLUDE (NAME, ADRESS, SHOESIZE);

• 优势：不需要修改原表结构，仅新增索引，对现有业务无影响；完全匹配查询需求，消除书签查找的额外开销。

2. 关于主键的选择（可选，非必需）

如果想给表补全主键约束，DNUM+ORDER_NUMBER是合理的组合，但这对当前查询的提升不如覆盖索引直接——主键会生成唯一索引，但索引仅包含DNUM和ORDER_NUMBER，查询时仍需要回表取NAME、ADRESS等列，效率低于覆盖索引。若只是为了优化这个查询，优先选覆盖索引即可。

3. 额外优化技巧

• 避免隐式类型转换：确保查询传入的DNUM值是CHAR(16)格式，不要传入数字或其他类型，否则DB2会触发隐式转换，导致索引失效，继续走全表扫描。
• 用临时表+JOIN替代IN子句：当IN子句包含1000个值时，DB2优化器的处理效率可能下降，改用临时表JOIN的方式往往更稳定：

  -- 创建临时表存储目标DNUM
  DECLARE GLOBAL TEMPORARY TABLE SESSION.DNUMS (DNUM CHAR(16) NOT NULL) ON COMMIT PRESERVE ROWS;
  -- 插入1000个DNUM值
  INSERT INTO SESSION.DNUMS VALUES ('DNUM_VALUE_1'), ('DNUM_VALUE_2'), ...;
  -- 给临时表加索引
  CREATE INDEX IX_SESSION_DNUMS ON SESSION.DNUMS (DNUM);
  -- 执行查询
  SELECT P.NAME, P.ADRESS, P.SHOESIZE 
  FROM PERSONTABLE P
  JOIN SESSION.DNUMS D ON P.DNUM = D.DNUM;
  

内容的提问来源于stack exchange，提问作者Zimeon