一个 ABAP 程序里可能只写了几行看起来非常普通的SELECT，到了 SAP HANA 数据库这一侧，却可能展开成包含几十张表、几十个 Join、多个 Filter、Aggregation、Projection、Calculation 的庞大执行图。尤其是在 SAP S/4HANA 里大量采用 ABAP CDS View、CDS View Entity、Association、DCL 和多层复用之后，应用层看到的模型结构与数据库真正收到的 SQL，往往已经不是一个复杂度级别。这也是理解 SAP HANA 查询性能时一个很关键的起点。SQL 是声明式语言。ABAP Open SQL 或 CDS 告诉数据库需要什么结果，却没有规定数据库必须按照什么步骤得到这些结果。同一个 SQL，可以先过滤再 Join，也可以在满足关系代数语义的情况下先 Join 再过滤，可以采用 Hash Join，也可能采用 Nested Loop Join，还可能重新安排多个 Join 的组合顺序。真正负责决定这些事情的是 SAP HANA SQL Optimizer。SAP 当前的 ABAP Data Models 官方文档把这一过程描述得相当清楚。SQL 进入 SAP HANA 后，会经过 SQL Plan Cache、SQL Front End、SQL Optimizer，最终生成 Execution Plan。Optimizer 又会经历逻辑重写以及 Cost-Based Optimization。逻辑阶段负责产生语义等价的变换，成本优化阶段则枚举不同 Logical Plan 和 Physical Plan，并根据统计信息估算成本，从大量候选方案中选择一个成本较低的执行计划。大量候选计划
一个 ABAP 程序里可能只写了几行看起来非常普通的SELECT，到了 SAP HANA 数据库这一侧，却可能展开成包含几十张表、几十个 Join、多个 Filter、Aggregation、Projection、Calculation 的庞大执行图。尤其是在 SAP S/4HANA 里大量采用 ABAP CDS View、CDS View Entity、Association、DCL 和多层复用之后，应用层看到的模型结构与数据库真正收到的 SQL，往往已经不是一个复杂度级别。这也是理解 SAP HANA 查询性能时一个很关键的起点。SQL 是声明式语言。ABAP Open SQL 或 CDS 告诉数据库需要什么结果，却没有规定数据库必须按照什么步骤得到这些结果。同一个 SQL，可以先过滤再 Join，也可以在满足关系代数语义的情况下先 Join 再过滤，可以采用 Hash Join，也可能采用 Nested Loop Join，还可能重新安排多个 Join 的组合顺序。真正负责决定这些事情的是 SAP HANA SQL Optimizer。SAP 当前的 ABAP Data Models 官方文档把这一过程描述得相当清楚。SQL 进入 SAP HANA 后，会经过 SQL Plan Cache、SQL Front End、SQL Optimizer，最终生成 Execution Plan。Optimizer 又会经历逻辑重写以及 Cost-Based Optimization。逻辑阶段负责产生语义等价的变换，成本优化阶段则枚举不同 Logical Plan 和 Physical Plan，并根据统计信息估算成本，从大量候选方案中选择一个成本较低的执行计划。大量候选计划
