尧图网页设计 
在一个典型的 SAP S/4HANA 采购订单数据模型里，明细数据和抬头数据经常被拆成不同的 CDS Entity。采购订单行项目负责物料、数量、工厂等信息，采购订单抬头负责订单状态、供应商、审批状态之类的信息。业务查询往往只关心某一个物料，理论上经过一个选择性很高的WHERE条件以后，真正需要参与后续处理的数据可能只剩几十条甚至几条。此时很容易产生一种直觉，SAP HANA 应该先把这几条数据筛出来，再去做JOIN，再针对最终留下来的记录执行计算字段。数据库处理的数据越少，CPU、内存以及中间结果集自然也越小。可是在某些 ABAP CDS 模型中，PlanViz 展现出来的实际执行计划完全不是这样。SAP HANA 可能不得不扫描关联右侧的大量数据，对几十万甚至几百万行逐行执行CASE、COALESCE或其他计算，形成一个巨大的中间结果集，再把这个结果拿去执行LEFT OUTER JOIN。左侧明明存在非常严格的过滤条件，右侧计算却像完全没有看到这个过滤条件一样。这种现象经常不是 SAP HANA Optimizer 不够聪明，而是数据模型通过一个很不起眼的表达式，把优化器能够采用的合法执行路径堵住了。这个表达式就是Not-Null Preserving Calculation。SAP 官方把Not-Null-Preserving Left Outer Join明确列为 CDS Entity 中比较典型的性能反模式。官方文档给出的核心判断非常明确，只要右侧存在一个 一个 ELSE 为什么会拖慢整条 CDS 查询，Not-Null Preserving Calculation 如何卡住 SAP HANA 优化器
在一个典型的 SAP S/4HANA 采购订单数据模型里，明细数据和抬头数据经常被拆成不同的 CDS Entity。采购订单行项目负责物料、数量、工厂等信息，采购订单抬头负责订单状态、供应商、审批状态之类的信息。业务查询往往只关心某一个物料，理论上经过一个选择性很高的WHERE条件以后，真正需要参与后续处理的数据可能只剩几十条甚至几条。此时很容易产生一种直觉，SAP HANA 应该先把这几条数据筛出来，再去做JOIN，再针对最终留下来的记录执行计算字段。数据库处理的数据越少，CPU、内存以及中间结果集自然也越小。可是在某些 ABAP CDS 模型中，PlanViz 展现出来的实际执行计划完全不是这样。SAP HANA 可能不得不扫描关联右侧的大量数据，对几十万甚至几百万行逐行执行CASE、COALESCE或其他计算，形成一个巨大的中间结果集，再把这个结果拿去执行LEFT OUTER JOIN。左侧明明存在非常严格的过滤条件，右侧计算却像完全没有看到这个过滤条件一样。这种现象经常不是 SAP HANA Optimizer 不够聪明，而是数据模型通过一个很不起眼的表达式，把优化器能够采用的合法执行路径堵住了。这个表达式就是Not-Null Preserving Calculation。SAP 官方把Not-Null-Preserving Left Outer Join明确列为 CDS Entity 中比较典型的性能反模式。官方文档给出的核心判断非常明确，只要右侧存在一个