如何高效查询SAP集群表CDPOS？

问题现状 #

查询SAP集群表CDPOS时性能极差，数据量较大时耗时数分钟甚至直接超时：测试场景中，35个ID查询耗时1分15秒，90个ID直接触发超时。

当前处理流程 #

• 根据用户指定日期筛选EKKO表中的采购订单
• 用筛选得到的采购订单ID过滤CDHDR表
• 以CDHDR返回的ID查询CDPOS表，最后通过CHECK语句过滤出目标非关键字段（注：CDPOS无日期字段，只能依赖ID进行过滤）

性能瓶颈代码 #

IF lt_chunk_cdhdr is not INITIAL.

    SELECT OBJECTID
           CHANGENR
           FNAME
           CHNGIND
           VALUE_NEW
           VALUE_OLD
      FROM CDPOS
      INTO TABLE lt_temp_cdpos
      FOR ALL ENTRIES IN lt_chunk_cdhdr
      WHERE OBJECTID = lt_chunk_cdhdr-objectid.

    LOOP AT lt_temp_cdpos INTO ls_cdpos.
      CHECK ls_cdpos-fname = 'FRGKE' AND ls_cdpos-value_new = '2'
         OR ls_cdpos-fname = 'MWSKZ'
         OR ls_cdpos-fname = 'KEY' AND ls_cdpos-chngind = 'I'
         OR ls_cdpos-fname = 'BRTWR'
         OR ls_cdpos-fname = 'NETWR'
         OR ls_cdpos-fname = 'ZTERM'
         OR ls_cdpos-fname = 'INCO1'.

      APPEND ls_cdpos TO lt_cdpos.
    ENDLOOP.
ENDIF.

已尝试的优化措施 #

• 遵循集群表优化规范，仅在WHERE子句中使用关键字段，后续通过CHECK过滤非关键字段，但效率仍未达标，80个ID左右的查询无法完成
• 限制查询周期为31天，但部分业务场景下仍会超时

集群表核心优化原则（翻译） #

集群表的优化逻辑与透明表完全相反：由于其特殊的存储方式，WHERE子句应仅包含关键字段，非关键字段的检查需放到数据查询完成后用CHECK命令处理。数据库无法像处理透明表那样直接解析集群表，若在SELECT的WHERE子句中加入非关键字段，会迫使数据库先解压所有匹配关键字段的数据再进行字段校验，这种方式在绝大多数场景下，比仅用关键字段过滤、返回数据后再做非关键字段检查的效率更低。

针对性优化建议 #

1. 补充关键字段过滤：CDPOS的关键字段包含OBJECTCLAS，采购订单对应的OBJECTCLAS值为'EINKBELEG'，在WHERE子句中加入该条件，能大幅减少需要解压和返回的数据量，这是最有效的优化点之一：

   WHERE OBJECTCLAS = 'EINKBELEG'
     AND OBJECTID = lt_chunk_cdhdr-objectid.
   

2. 清理内表重复数据：确保lt_chunk_cdhdr内表没有重复的OBJECTID（若包含OBJECTCLAS则需组合去重），FOR ALL ENTRIES会对内表的每条记录发起查询，重复条目会导致冗余查询，浪费资源。
3. 缩小分块粒度：当前的分块大小（80-90个ID）仍过大，建议将分块调整为20-30个ID一组，分批执行查询，避免单次请求占用过多数据库资源导致超时。
4. 提前关联CDHDR的关键信息：从CDHDR查询时，可以同时获取OBJECTCLAS字段，确保后续查询CDPOS时的关键字段完整性，避免不必要的范围查询。

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