写 ABAP CDS 久了，很容易形成一种经验判断。一个 CDS View 里虽然关联了很多表，但上层程序只读取主表字段，SAP HANA 应该会聪明地把那些没用到的 Join 干掉。
这个判断有时完全正确，有时却会把我们带进一个很隐蔽的坑。
真正麻烦的地方并不是 Join 有没有被执行，而是 cardinality 一旦声明错了，同一个 CDS View，仅仅改变SELECT字段列表，最终返回的行数都可能发生变化。更极端一点，一个列表显示 19885 行，而同一个 View 上执行COUNT(*)却只有 2566。代码没有换，过滤条件没有换，数据也没有换，仅仅是读取字段不同，结果集已经不是同一个世界。
这不是理论上的边角案例，而是在 SAP S/4HANA 2020 和 SAP S/4HANA 2023 两套实验系统上实际测出来的结果。实验分别使用 SAP_BASIS 755 搭配 SAP HANA 2.00.052，以及 SAP_BASIS 758 搭配 SAP HANA 2.00.073。2023 系统里有 1199 个物料、2051 条物料文本，2020 系统里有 2566 个物料、19885 条多语言文本。实验围绕MARA、MAKT、T134构造了八种不同 Join 写法，再通过真实 ABAP SQL 进入 HANA SQL Plan Cache，最后对缓存里的真实 SQL 做EXPLAIN PLAN。因此这里讨论的不是凭经验猜 Optimizer 会做什么，而是直接观察 Optimizer 生成的执行计划。
SAP HANA
