System Power/AS400 RPGLE嵌入式SQL游标首次Fetch缓慢问题咨询

在IBM i（AS/400）环境下，用RPGLE程序的嵌入式SQL实现Subfile时，遇到以下问题：当查询数据量较大时，游标首次Fetch操作速度很慢，但滚动（重新打开游标Fetch后续数据）时速度正常；哪怕只选取19行且每次仅Fetch一行，首次Fetch的慢响应问题依然存在。

相关代码片段 #

sqlCmd = 
   ' select ... 
      offset ? rows +
     fetch first '+%CHAR(maxRecnum +1)+' rows only +
    ) as fuse +
     order by rownumber asc +
   ';
  exec sql PREPARE S1 FROM :sqlCMD;
  exec sql DECLARE getS1 scroll CURSOR FOR S1;
  exec sql OPEN getS1 USING :xy;

OU SQLCODE <> 0 or Recnum1 > maxRecnum +1;

    exec sql
      fetch getS1 
        into
          :rownumberH
         ,:Spalte1 :NullIDx_SyvWerte
         ,:Spalte2 :NullIDx_SyvWerte
         ,:Spalte3 :NULLIDXW
         ,:Spalte5 :NullIDx_SyvWerte                           
         ,:Spalte6 :NullIDx_SyvWerte
         ,:Spalte7 :NullIDx_SyvWerte
         ,:Spalte8 :NullIDx_SyvWerte
         ,:Spalte9 :NullIDx_SyvWerte
         ,:Spalte10 :NullIDx_SyvWerte
         ,:Spalte11 :NullIDx_SyvWerte
         ,:KYH :NullIDx_SyvWerte                     
         ,:FUNKTH :NullIDx_SyvWerte
         ,:WERTH :NULLIDXH
         ,:UntermenueKY :NullIDx_SyvWerte
         ,:KYALTH :NullIDx_SyvWerte
         ,:SpalteK :NullIDx_SyvWerte               
         ,:MASKH :NullIDx_SyvWerte
         ,:POSH :NullIDx_SyvWerte
         ,:WertLaengH :NullIDx_SyvWerte
         ,:Menu :NullIDx_SyvWerte
         ,:sMenuLastChgDate :NullIDx_SyvWerte
         ,:sMenuLastChgTime :NullIDx_SyvWerte
         ,:sMenuLastCrtDate :NullIDx_SyvWerte
         ,:sMenuLastCrtTime :NullIDx_SyvWerte
         ,:WertVergleich :nullIDxWert
         ,:VarianteAusgelaufen :NullIDx_SyvWerte
         ,:DatAus
         ,:id_YSYVH     :NullIDx_SyvWerte
         ,:SbH          :NullIDx_SyvWerte
         ,:LgH          :NullIDx_SyvWerte
         ;

    If sqlcode <> 0 or Recnum1 > maxRecnum;   
    leave;
    ENDIF;   

补充说明 #

首次显示19行后关闭游标，滚动时重新打开游标，问题集中在首次Fetch环节。

问题原因 #

• 排序与结果集预构建开销：SQL中使用了ORDER BY rownumber asc结合OFFSET/FETCH分页，首次打开游标时，DB2 for i需要先对全量符合条件的数据完成排序，构建好完整的有序结果集才能支持OFFSET和FETCH操作。这个排序和结果集准备过程的耗时会被计入首次Fetch的响应时间，而后续滚动重新打开游标时，系统可能缓存了排序结果或临时表，开销大幅降低。
• 动态SQL的首次编译开销：代码采用动态SQL（PREPARE语句），首次执行时需要完成语句解析、访问计划生成与优化，这些操作的开销会直接导致首次Fetch延迟。后续滚动时，DB2的包缓存会复用已生成的访问计划，规避了预编译开销。
• NULL指示器的初始化开销：Fetch语句包含大量NULL指示器变量，首次Fetch时DB2需要建立这些变量与查询字段的映射关系并完成初始化，后续Fetch因为映射已存在，这部分开销消失。
• OFFSET的初始扫描开销：即使首次OFFSET为0，DB2在处理OFFSET/FETCH时也需要完成结果集的定位与初始化扫描，这个过程在首次执行时没有缓存加持，耗时会比后续重复操作更长。

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