在 SAP S/4HANA 项目里，我们经常会遇到一种很有迷惑性的性能问题。某个 CDS View 单独执行很快，上面再叠一层 CDS View 似乎也没有问题，再继续加入 Association、计算字段、权限控制和聚合之后，业务功能仍然能够正确运行。直到某一天，生产系统的数据量增长到几千万甚至上亿条，原本几百毫秒返回的查询突然变成数秒，偶尔甚至几十秒。同样一段 ABAP Open SQL，在测试系统里运行飞快，到了生产系统却完全是另一幅景象。更麻烦的情况是，同一条 SQL 昨天执行很快，今天执行却突然变慢。这类问题如果只盯着 CDS 源代码，很容易陷入局部分析。真正决定运行时间的，并不是 CDS 文件看起来有多少行，而是 CDS 最终形成怎样的 SQL 关系模型，SAP HANA SQL Optimizer 又为它选择了怎样的执行计划。理解这一层，是分析 CDS Performance 最重要的基础之一。CDS 强大的地方，在于每一个 CDS Entity 都可以继续像一张关系表一样被其他 CDS Entity 使用。从 Relational Algebra 的角度看，一个 CDS Entity 可以视为一个 relation。我们可以把销售订单、客户、产品、价格、库存、权限、币种换算等业务逻辑分别封装到不同 CDS 层，再将这些实体继续组合。这种设计给应用建模带来了非常强的表达能力，也带来了一个直接后果，应用层看到的一个简单 CDS Entity，到了数据库层面可能已经展开成非常复杂的 SQL 查询图。例如一个用于销售分析的 Consumption View，看上去也许只暴露二十几个字段，但它的下层可能依赖订单头、订单行项目、客户主数据、
