Db2 for i自定义视图首次运行慢的性能优化方法咨询

针对IESQAFILE.PSCMPORDVW视图“首次运行慢、重复调用快、Visual Explain无索引优化建议”的问题，先明确核心诱因：Db2 for i的SQL作业会将访问过的数据页、生成的执行计划缓存到作业内存池，首次运行时需要磁盘IO读、生成执行计划、冷数据加载，自然耗时更长；后续调用命中缓存后速度提升，并非执行逻辑本身被优化。

一、SQL结构层面无成本优化（零资源消耗） #

这类隐蔽性能损耗是Visual Explain经常识别不到的——工具基于热缓存下的执行路径做分析，不会捕捉结构化逻辑带来的冗余开销：

• 删除CTE冗余排序逻辑：INPROGRESS、STOPGROUP两个公共表表达式内部写了ORDER BY 1的排序逻辑，但这两个是中间计算结果集，外层查询没有对这两个结果集做顺序要求，V7R4M0优化器不会自动裁剪这类显式排序操作，会额外消耗CPU和内存做无意义排序，直接删除这两处CTE内的ORDER BY语句即可。
• 消除重复标量子查询：现有SQL里3处CASE WHEN逻辑，都重复执行了读取QSYS2.DATA_AREA_INFO('COMPAN', '*LIBL')取时区值的操作，该值为系统固定常量，V7R4M0不会自动做常量折叠，每输出一行结果就会触发一次数据区域读取，行数较多时会产生大量冗余IO。优化方式为在CTE开头新增单值结果：

  COMPAN_TZ AS (
    SELECT SUBSTR(DATA_AREA_VALUE, 1109, 2) AS TIMEZONE 
    FROM TABLE(QSYS2.DATA_AREA_INFO('COMPAN', '*LIBL'))
  )
  

  后续所有CASE逻辑直接关联这个CTE取固定时区值，无需重复读取数据区。
• 清理冗余关联与过滤条件：外层查询WHERE子句重复写入了DIETAD <> 0 AND DIETAT <> '0000'，该条件已在INPROGRESS CTE中完成过滤；原有EXCEPTION JOIN逻辑中，跨表引用PSMAINORVW的ORARST = '1'作为关联条件，容易导致优化器选错关联顺序，提前触发大表全扫，建议把这个筛选条件下移到PSMAINORVW的子查询内部做预过滤，从源头减少主表的输入行数。

二、索引匹配优化（解决Visual Explain无建议的问题） #

Visual Explain默认基于热缓存场景生成计划，看不到冷启动时全表扫的性能损耗，可按照视图的关联、过滤逻辑手动建覆盖索引，无需等工具提示：

• 针对IESQAFILE.LOAD表：建索引(DIETAD, DIETAT, DIODR#, DIDISP, DIUNIT, DISTST, DIAPRV, DITRLR, DIDR1)，完全覆盖INPROGRESS CTE的过滤、取数字段，直接走覆盖索引，无需读取基础表数据。
• 针对PAVT.STOP表：建索引(SOORD, SOARDT, SOSTP#, SOAPPR)，完全覆盖STOPGROUP CTE的关联、过滤、聚合计算字段，无需扫全表计算聚合值。
• 针对IESQAFILE.STOPOFF表：建索引(SOORD, SOSTP#, SOCUST, SOEDA, SOETA, SOADT1, SOATM1, SOADT2, SOATM2, SOCTYC, SOST, SOARDT, SOARTM, SOLUDT, SOLUTM)，同时覆盖和STOPGROUP的下停靠点关联、外层SOSTP#=90的关联取数需求。
• 剩下的关联表IESQAFILE.UNITS、IESQAFILE.SUPMAST、IESQAFILE.FLTMAST、IESQAFILE.LMCARR、IESQAFILE.MMILES、IESQAFILE.ORDBILL，均按关联主键字段建前置索引，保证关联时走索引匹配，避免全表扫。

三、冷启动慢问题的配套优化 #

• 重新跑执行计划时，选择Visual Explain的「模拟冷缓存」选项，不要直接读取生产上已执行过的作业计划，否则优化器默认基于内存命中场景做判断，不会输出索引优化建议。
• 定期对视图涉及的所有表执行RUNSTATS更新统计信息，避免优化器因行数估算偏差选错关联顺序，导致全表扫。
• 业务低峰期可做一次缓存预热，即执行一次简单的视图查询，将涉及的表数据页提前加载到内存池，避免早高峰首次访问时触发冷磁盘IO。

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