在 SAP S/4HANA 项目里，有一类 CDS View 单独拿出来看完全没有问题，甚至每一层都显得很合理。底层为了把两个结构相同的数据源拼在一起，使用UNION ALL。上层为了补充一些可选属性，再通过 Association 建立LEFT OUTER JOIN。最上层的 ABAP SQL 又带着一个选择性非常高的WHERE条件，只查询某个业务对象。代码看起来很干净，数据库里真正发生的事情却可能完全是另一幅景象。我们原本只需要几十条甚至几条记录，SAP HANA 却可能先处理数百万乃至数亿行数据，将多个分支合并成一个庞大的中间结果，再参与外连接。CPU 时间升高只是表象，更棘手的是 temporary memory 暴涨、statement memory limit 被触发、并发查询互相争抢内存，最终表现为一个看起来非常简单的 CDS 查询响应几十秒甚至几分钟。SAP 已经在 ABAP Data Models 官方文档中把这种组合明确列入 anti-pattern，并给出了非常直白的判断，Union views与left outer joins组合时，由于缺乏有效的 filter push-down，可能产生复杂执行计划以及巨大的中间结果物化。