在 SAP S/4HANA 项目里，有一种性能问题非常容易被低估。某个 CDS View Entity 单独做 Data Preview 时速度并不慢，底层表也有合适的字段，业务数据量看起来没有离谱，真正被 RAP Service、OData、Fiori Elements 或上层 CDS 消费以后，响应时间却突然从几百毫秒拉长到数秒，甚至伴随着 SAP HANA 内存占用明显增加。这种问题经常不是因为 Join 数量太多，也不一定是数据库缺索引，而是因为一个看起来很普通的 calculated field 被放到了执行计划中的关键位置。所谓 calculated field，就是数据库表本身没有持久化保存该字段值，而是在查询执行期间临时计算出来的字段。CDS 中相当多的表达式都会形成这种字段，例如caseexpression、字符串拼接、算术运算、类型转换以及各种 built-in function。SAP 官方 ABAP Data Models 文档对这一点给出的警告相当明确。计算字段如果参与大数据量处理，计算必须先被求值，某些情况下还需要将中间结果 materialize，从而扩大内存占用并延长运行时间。官方甚至把 calculated field 出现在关键查询位置列入 CDS anti-pattern。SAP Help Portal问题并不是 CDS 不应该计算数据。真正需要警惕的是计算发生在什么地方 SAP ABAP CDS 性能优化深度解析，从 calculated field、Filter Pushdown 到 Left Outer Join 的执行代价
在 SAP S/4HANA 项目里，有一种性能问题非常容易被低估。某个 CDS View Entity 单独做 Data Preview 时速度并不慢，底层表也有合适的字段，业务数据量看起来没有离谱，真正被 RAP Service、OData、Fiori Elements 或上层 CDS 消费以后，响应时间却突然从几百毫秒拉长到数秒，甚至伴随着 SAP HANA 内存占用明显增加。这种问题经常不是因为 Join 数量太多，也不一定是数据库缺索引，而是因为一个看起来很普通的 calculated field 被放到了执行计划中的关键位置。所谓 calculated field，就是数据库表本身没有持久化保存该字段值，而是在查询执行期间临时计算出来的字段。CDS 中相当多的表达式都会形成这种字段，例如caseexpression、字符串拼接、算术运算、类型转换以及各种 built-in function。SAP 官方 ABAP Data Models 文档对这一点给出的警告相当明确。计算字段如果参与大数据量处理，计算必须先被求值，某些情况下还需要将中间结果 materialize，从而扩大内存占用并延长运行时间。官方甚至把 calculated field 出现在关键查询位置列入 CDS anti-pattern。SAP Help Portal问题并不是 CDS 不应该计算数据。真正需要警惕的是计算发生在什么地方 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
