电商促销结束后，订单系统里留下成千上万条待处理记录。运营希望尽快看清哪些订单仍未完成，财务希望汇总金额，仓库希望收到可以继续履约的订单。如果程序逐条读取、逐条计算、逐条更新，屏幕上看似不断有动作，数据库和应用服务器却可能被往返请求拖慢。这种场景很适合借赵灵儿的「风卷残云」来想象一套 ABAP 技术组合，一阵风覆盖大量目标，把该筛选的筛选、该汇总的汇总、该处理的处理。ABAP 没有名叫「风卷残云」的语句或标准组件。这个比喻最贴近的是面向集合的数据处理，再配合有边界的批量执行业务操作。它也提醒我们，一招打中很多目标，并不等于对所有目标使用同一种更新，更不等于执行一条没有限制条件的UPDATE。在企业系统里，订单是否允许修改、库存是否足够、用户是否有权限、保存失败后怎样恢复，都属于这阵风必须遵守的规则。我通常把「风」理解为处理范围，把「卷」理解为尽量让数据库完成筛选与聚合，把「残云」理解为完成操作后留下清楚的成功、失败与待重试记录。三个部分缺一块，程序可能跑得很快，却难以确认究竟处理了什么。以订单监控为例，我们要知道某个日期以来，各状态下分别有多少订单。较直接的做法，是将符合条件的订单全部读进内表，再在 ABAP 里逐行累计。订单量小时，这种写法容易理解。订单量增大后，应用服务器需要接收许多其实并不需要展示的明细，数据库与应用服务器之间也多了数据传输。更合适的写法，是让数据库按状态分组，只把每组的计数送回来。下面的代码以自建订单表zsales_order为示意。字段与命名只是为了说明查询形态，实际项目需要替换成我们的数据模型。