最近在分析一些复杂的 SAP ABAP CDS View 时，我越来越倾向于把注意力从 CDS 源代码本身，往下移动一层，直接去看最终交给 SAP HANA 的 SQL。原因很简单。有些 CDS 写法在 ABAP Development Tools 里看起来非常自然，association 也写得很漂亮，cardinality 看起来没有明显问题，业务语义同样能解释得通，可一旦数据量上来，执行时间、CPU 消耗和内存占用却会突然恶化。Non-Equi Left Outer Join 就属于这一类问题。SAP 已经把它列入 ABAP Data Models 中需要警惕的 anti-pattern。问题并不在于 non-equi join 本身不能使用，而在于它一旦和 left outer join 组合起来，就可能触发 SAP HANA 执行引擎不太理想的执行路径。SAP 当前文档明确指出，SAP HANA column engine 并不能原生处理这种组合，在某些执行路径中需要发生 engine switch。理解这个问题之前，需要先把 equijoin 和 non-equi join 分开。最常见的 join 条件是这样的。a.Field1=b.Field1两个数据源之间通过等号建立匹配关系，这就是 equi 
长河君 · 2026/10/16 3:09:36 · 阅读 1.2k SAP ABAP CDS 性能优化中的隐形陷阱，Non-Equi Left Outer Join 为什么会拖慢 HANA
最近在分析一些复杂的 SAP ABAP CDS View 时，我越来越倾向于把注意力从 CDS 源代码本身，往下移动一层，直接去看最终交给 SAP HANA 的 SQL。原因很简单。有些 CDS 写法在 ABAP Development Tools 里看起来非常自然，association 也写得很漂亮，cardinality 看起来没有明显问题，业务语义同样能解释得通，可一旦数据量上来，执行时间、CPU 消耗和内存占用却会突然恶化。Non-Equi Left Outer Join 就属于这一类问题。SAP 已经把它列入 ABAP Data Models 中需要警惕的 anti-pattern。问题并不在于 non-equi join 本身不能使用，而在于它一旦和 left outer join 组合起来，就可能触发 SAP HANA 执行引擎不太理想的执行路径。SAP 当前文档明确指出，SAP HANA column engine 并不能原生处理这种组合，在某些执行路径中需要发生 engine switch。理解这个问题之前，需要先把 equijoin 和 non-equi join 分开。最常见的 join 条件是这样的。a.Field1=b.Field1两个数据源之间通过等号建立匹配关系，这就是 equi