SAP ABAP CDS 性能优化实战，计算字段、Association、Union、权限控制与数据库 Hint 的代价

在 SAP S/4HANA 项目里做 CDS 数据模型时，经常会遇到一种很有迷惑性的情况。某个 CDS View Entity 单独预览只有几十毫秒，字段也不算多，SQL 看起来甚至相当规整，可一旦被上层 Consumption View、RAP Query、OData 服务或者 Analytical Query 消费，响应时间突然从几百毫秒拉长到数秒，内存占用也明显增加。

问题往往不在于 CDS 层级多了几层，也不一定是底层表数据量太大。更常见的原因，是模型中某些看似普通的特性改变了 SAP HANA SQL Optimizer 能够采用的优化策略。

CASE、算术表达式、Association、UNION、DCL Access Control、Path Expression、数据库 Hint，这些功能本身都没有问题。真正需要关注的是它们出现在查询执行树的什么位置，以及它们会不会妨碍 Filter Pushdown、Join Pruning、Predicate Pushdown、Join Reordering、Union Branch Pruning 等数据库优化动作。

SAP 当前的 ABAP Data Models 文档仍然把Not-Null-Preserving Left Outer Join、Non-Equi Left Outer Join、Disjunction Join、Union in Left Outer Joins和关键位置上的 Calculated Field 列为典型性能反模式。共同原因非常接近，一旦表达式迫使 SAP HANA 提前计算大