从扫描到索引：SAP HANA 查询处理路径与优化技巧的落地实战

在本地部署的 SAP HANA 与 SAP HANA Cloud 场景里，大家经常会有一种错觉：数据都在内存里，查询自然就快。现实却更像一场高速公路的通行效率比拼——同一辆车（同一条 SQL），走不同的入口匝道（不同的访问路径），能差出几个数量级。真正决定你能不能秒开业务界面、能不能把批处理窗口压到可控范围内的，往往不是硬件堆料，而是优化器能否选到合适的访问路径，以及你给了它哪些可选项：列存扫描、单列索引、拼接索引、分区裁剪，甚至是它们的组合拳。

下面用一个非常典型的多谓词查询作为主线，拆解 SAP HANA 在不同访问路径下的执行方式与成本差异，并穿插真实业务里常见的案例，帮助你把抽象概念落到可以操作的设计与诊断方法上。

场景设定：一条看似普通的多谓词查询

假设我们有一张列存表FOO，主键由三个字段组成：

• MANDT：客户端（多租户隔离字段，很多 ABAP 表都有）
• BELNR：单据号（例如财务凭证号、业务单号一类）
• POSNR：行项目号（同一单据下的行号）

查询语句如下：

SELECT*FROMFOO