寫 ABAP CDS 久了，很容易形成一種經(jīng)驗(yàn)判斷。一個 CDS View 里雖然關(guān)聯(lián)了很多表，但上層程序只讀取主表字段，SAP HANA 應(yīng)該會聰明地把那些沒用到的 Join 干掉。這個判斷有時完全正確，有時卻會把我們帶進(jìn)一個很隱蔽的坑。真正麻煩的地方并不是 Join 有沒有被執(zhí)行，而是 cardinality 一旦聲明錯了，同一個 CDS View，僅僅改變SELECT字段列表，最終返回的行數(shù)都可能發(fā)生變化。更極端一點(diǎn)，一個列表顯示 19885 行，而同一個 View 上執(zhí)行COUNT(*)卻只有 2566。代碼沒有換，過濾條件沒有換，數(shù)據(jù)也沒有換，僅僅是讀取字段不同，結(jié)果集已經(jīng)不是同一個世界。這不是理論上的邊角案例，而是在 SAP S/4HANA 2020 和 SAP S/4HANA 2023 兩套實(shí)驗(yàn)系統(tǒng)上實(shí)際測出來的結(jié)果。實(shí)驗(yàn)分別使用 SAP_BASIS 755 搭配 SAP HANA 2.00.052，以及 SAP_BASIS 758 搭配 SAP HANA 2.00.073。2023 系統(tǒng)里有 1199 個物料、2051 條物料文本，2020 系統(tǒng)里有 2566 個物料、19885 條多語言文本。實(shí)驗(yàn)圍繞MARA、MAKT、T134構(gòu)造了八種不同 Join 寫法，再通過真實(shí) ABAP SQL 進(jìn)入 HANA SQL Plan Cache，最后對緩存里的真實(shí) SQL 做EXPLAIN PLAN。因此這里討論的不是憑經(jīng)驗(yàn)猜 Optimizer 會做什么，而是直接觀察 Optimizer 生成的執(zhí)行計(jì)劃。SAP HANA