月末结算窗口只剩两小时，三万笔销售返利申请还停在待处理状态。业务部门希望一次执行，把符合条件的申请全部处理完。开发人员手里有数据库的更新语句，也有后台作业和并行处理能力，看起来只要把批量开大，就能赶上结算时间。真正需要算清楚的却是另一笔账，数据库负载、锁等待、失败后的重试成本，以及每笔返利原本应当经过的业务校验。这个场景很像林月如的乾坤一掷。招式的吸引力在于投入资源，换取对一片目标的强力攻击。放进 ABAP 世界，最贴切的对应物不是某条神奇指令，而是一种工程决策，我们愿意为一次大范围业务处理投入多少系统资源，能够承受多大失败代价，是否还能保持每笔业务结果正确。需要把类比的边界立住。ABAP 没有名叫乾坤一掷的语言特性，执行UPDATE也不会自动让业务处理变强。一次更新碰到很多行，只能说明数据库操作范围大，不能说明这些行都适合走同一条业务路径。钱掷出去之前，目标是谁、代价是多少、退路在哪里，比出手姿势更重要。游戏里的铜钱在系统中可以对应几种不同的预算。最直观的是计算资源，包括数据库 CPU、内存、日志写入量、应用服务器工作进程和网络传输量。另一种是事务预算，一次操作究竟包住多少业务对象，失败时要回滚多少工作，重试时要重新检查多少数据。还有一种容易漏算的预算是运营能力，结算人员能否看出哪些申请成功、哪些失败，能否只补处理失败的部分。假如三万笔返利申请每笔都要检查合同有效期、返利上限和审批状态，把它们当成三万行普通记录执行一次UPDATE，数据库可能很快返回成功。业务结果却可能无法使用，因为字段变化并不等于返利流程已经完成。审批规则、变更记录、后续事件及相关业务对象，都可能由应用层的业务逻辑负责。用 SQL 直接改表，就像只看见招式命中了三万个位