在 SAP S/4HANA 项目里，有一类 CDS View 看起来非常漂亮。字段命名整齐，业务主键也被拼成了一个完整字符串，上层 ABAP、RAP、OData 或 Fiori 只需要拿着这个字符串去查询，看起来甚至比传递四五个字段更加方便。代码可能只有几行。真正到了生产系统，底层业务表从几万条记录增长到几百万、几千万甚至上亿条之后，同一条查询却可能突然从几十毫秒变成几秒，严重时还会伴随 SAP HANA 内存消耗快速增长。很多时候，问题并不在 CDS 层级太深，也不在数据库缺索引，而是一个非常不起眼的设计决定。把 calculated field 放到了过滤、连接、排序或者其他数据库执行计划中的关键位置。SAP 当前的 ABAP Data Models 文档已经把Avoid Calculated Fields in Critical Positions明确列入 CDS 数据模型的 anti-pattern。SAP 给出的原因很直接，字段计算必须在字段能够参与后续处理之前完成，而处理大数据量时，这类计算可能要求数据库物化 intermediate data set，从而增加内存占用。这里真正需要理解的，并不是简单记住一条开发规范，而是理解 SAP HANA 在执行下面这类 SQL 时究竟发生了什么。一个看起来非常合理的 CDS Key来看这样一个 CDS View Entity。业务表中原本存在col1、col2、col3、