从 CDS 到执行计划，深入理解 SAP HANA 数据库的 Query Processing 机制

在 SAP S/4HANA 项目里，一个很容易让开发人员产生误判的场景，是某个 CDS View Entity 看起来并不复杂，ABAP 程序里也只是写了一条普通的SELECT，真正运行时却可能需要几秒甚至几十秒。另一个 CDS 模型看起来有七八层甚至十几层，里面包含大量 Association、Join 和表达式，执行速度反而非常快。如果只盯着 CDS 源代码，很难解释这种现象。问题的关键不在于 CDS 文件有多少行，也不能简单按照 CDS 有多少层来估算运行时间。真正决定数据库访问性能的，是这些 CDS 定义最终转换成怎样的 SAP HANA SQL，SAP HANA SQL Optimizer 能否有效地重写查询，过滤条件能否向底层下推，不需要的列和 Join 能否被裁剪，Join 顺序能否合理安排，以及数据库最终选择了怎样的执行计划。这也是理解 CDS Performance 时必须掌握的一层知识。CDS 负责表达我们想得到什么数据，SAP HANA Query Processor 则负责决定这些数据到底怎样得到。SAP 官方对 ABAP CDS 架构的描述非常明确。CDS 对象在 AS ABAP 上使用 CDS DDL 定义，数据库接口会把这些定义转换成 SAP HANA 能够理解的 Native SQL。对于持久化 CDS Entity，SAP HANA 数据库侧会生成相应的数据库 Artifact。对于 Analytical Query 一类 Transient Entity，则不存在对应的持久化数据库 Artifact。这个区别看似只是实现细节，实际上直接影响我们理解整个 CDS 性能模型的方式。