企业官网建设流程全解析

在 SAP 项目里，经常会遇到一种很有诱惑力的设计思路，把业务逻辑尽可能塞进一条 SQL 或一套层层嵌套的 CDS View，让 SAP HANA 一次性完成过滤、连接、聚合、计算和排序。按照数据库下推的理念看，这种写法似乎天然应该是性能最优解。

可真正做到一定规模以后，会出现另一类问题。

一条查询可能经过十几层 CDS View，底层关联 VBAK、VBAP、VBEP、MARA、MARC、KNA1、KNVV、TVAK、T001W 等数据源，中间夹杂LEFT OUTER JOIN、Association、计算字段、CASE、UNION、聚合、参数化 CDS、权限过滤、日期计算，最外层又带上业务用户传入的动态过滤条件。

从 ABAP 源代码表面看，它仍然只是一个SELECT。

到了 SAP HANA 内部，它已经完全不是我们肉眼看到的那个结构。

SAP HANA 的 SQL Optimizer 会对查询树做规则改写，也会进行基于成本的优化。优化器会考虑表统计信息、数据量、过滤选择性、Join 基数、访问路径、Join 顺序、算子实现方式以及候选执行计划的成本，再从候选方案中选择执行计划。SAP 官方文档也特别强调，测试系统中数据很少时形成的执行计划，与生产系统面对数亿条记录时形成的计划可能明显不同。