让 Join 谓词更可被优化：SAP HANA 中的谓词重排、执行计划陷阱与工程化落地

在 SAP HANA（无论是本地部署还是 SAP HANA Cloud）里，很多性能事故都不是因为硬件不够、表不够大，而是因为一条看起来很普通的WHERE条件，让优化器不得不走一条“看得懂但跑不快”的路线。尤其是那类把两张表的列混在同一侧做运算的谓词，例如A1 - B1 = 1。这类写法往往会让执行计划里出现非常不讨喜的结构：先做CROSS PRODUCT（笛卡尔积）再做 post-join filter（连接后过滤），中间结果膨胀得极其夸张，CPU、内存与网络（分布式场景）都可能被拖进泥潭。SAP 的性能建议也明确提到：当过滤谓词在比较符一侧同时引用两张或多张关系（表/视图）时，可能无法被高效处理，并倾向于在CROSS PRODUCT之上出现低效的连接后过滤算子。(SAP Help Portal)

下面这篇文章会以一个“资深 SAP HANA 技术专家”的视角，把这个问题讲透：为什么会慢、为什么优化器不一定敢自动改、怎么通过“谓词重排”把执行计划从危险边缘拉回来，以及在真实项目里如何用可落地的方式把它固化为团队的编码习惯。