Progress 4GL查询调优：20万+记录更新耗时19小时如何优化？

以下是针对你提供的批量更新代码的具体优化措施，从临时表设计、查询逻辑、事务处理等多个维度降低耗时：

1. 给临时表添加索引，加速过滤与关联 #

原临时表tdata未定义索引，导致删除空tptpart记录、关联xx_mstr时需全表扫描，对20万级数据是极大性能消耗。修改临时表定义，添加针对tptpart的唯一索引：

DEFINE TEMP-TABLE tdata no-undo
  field tptpart as character
  field tptsts  as character
  field ttype   as character
  INDEX idx_tptpart IS UNIQUE PRIMARY tptpart. // 添加唯一索引

2. 导入阶段直接过滤无效记录，减少后续处理 #

原代码先导入所有记录再删除空tptpart行，浪费内存和处理时间。可在导入时直接跳过无效行：

INPUT FROM /sdd/aert/import.csv.
repeat:
  CREATE tdata.
  IMPORT DELIMITER "," tdata NO-ERROR. // 用NO-ERROR避免导入错误中断流程
  IF tdata.tptpart = "" THEN DELETE tdata. // 即时删除无效记录
END.
INPUT CLOSE.

3. 用关联查询替代嵌套循环，减少单条查询开销 #

原代码对每条临时表记录单独执行一次FOR FIRST xx_mstr，20万次单表查询的上下文切换和数据库交互开销极大。改成关联查询，让数据库一次性处理匹配逻辑：

etime(true).
SET TRANSACTION MODE BATCH. // 开启批量事务模式，减少日志写入

DEFINE VARIABLE iCount AS INTEGER NO-UNDO.

FOR EACH tdata,
     FIRST xx_mstr WHERE xx_domain = "XX" 
                   AND xx_part = tdata.tptpart
                   EXCLUSIVE-LOCK USE-INDEX xx_part:
  ASSIGN
    xx_mstr.xx_status = tdata.tptsts // 修正原代码变量名错误（原ttptsts应为tdata.tptsts）
    xx_mstr.type = tdata.ttype.
  
  iCount = iCount + 1.
  IF iCount MOD 1000 = 0 THEN DO: // 每1000条提交一次事务
    COMMIT.
    iCount = 0.
  END.
END.

IF iCount > 0 THEN COMMIT. // 提交剩余未完成的事务

MESSAGE "This took" ETIME "milliseconds" VIEW-AS ALERT-BOX.

4. 优化事务提交策略，降低日志IO开销 #

Progress默认每条更新自动提交，20万条更新会产生大量事务日志写入。开启BATCH事务模式，并批量提交（比如每1000条提交一次），可大幅减少磁盘IO次数，提升整体速度。

5. 验证xx_mstr索引有效性，确保查询走最优路径 #

确认xx_mstr表的xx_part索引包含xx_domain字段，或直接创建复合索引xx_domain + xx_part——如果现有索引仅包含xx_part，查询条件xx_domain = "XX" AND xx_part = ...无法高效利用索引，需创建复合索引：

// 在数据库中创建复合索引（需管理员权限）
CREATE INDEX idx_xx_domain_part ON xx_mstr (xx_domain, xx_part) PRIMARY.

6. 删除不必要的锁释放操作 #

原代码中的RELEASE xx_mstr是多余的——FOR FIRST xx_mstr循环结束时，Progress会自动释放锁，手动释放反而增加额外开销，直接删除该语句即可。

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