CDS Performance 深入解析，从 SAP HANA 执行计划到 ABAP CDS 建模优化

在 SAP S/4HANA 项目里，经常会碰到一种很有迷惑性的性能问题。某个 ABAP CDS View 单独打开，看起来只有几十行代码，字段不多，WHERE条件也很简单，可一旦被上层 RAP、Fiori Elements、OData 或另外几层 CDS View 消费，最终 SQL 的执行时间却可能从几十毫秒膨胀到几秒，甚至更久。问题往往不在眼前看到的这几十行 CDS，而在整个 CDS 数据模型经过 SAP HANA 展开之后形成的执行结构。这也是理解 CDS Performance 最重要的入口。ABAP CDS 最大的价值，是把数据库访问从传统的命令式编程进一步推向声明式数据建模。开发人员描述需要什么数据、数据之间有什么关系、有哪些计算、哪些字段具有业务语义，而具体采用什么 Join 顺序、在哪个阶段执行 Filter、是否进行 Join Pruning、哪个算子并行执行、何时进行 Aggregation，这些工作大量交给 SAP HANA Query Optimizer。这种开发模式非常强大。同一个 CDS Entity 可以继续成为另一个 CDS Entity 的数据源，一个基础 View 可以构成 Composite View，一个 Composite View 又可以被 Consumption View 使用。RAP Business Object、Analytical Query、OData Service 和 Fiori Elements 都可以继续站在这套模型之上。SAP 官方文档也明确指出，CDS Entity 可以像关系一样被继续复用，因此可以通过多层 CDS Entity 把复杂业务逻辑分解到不同层次。不过，