从 ABAP SQL 到 SAP HANA 执行计划，彻底理解 Dynamic Cache 的运行时机制

在一个典型的 SAP S/4HANA 业务系统里，真正拖慢数据库访问的查询，很多时候并不是简单的主键读取，而是对大表反复执行相似的聚合计算。财务程序不断按公司代码和会计年度汇总金额，销售分析不断按组织维度计算订单数量和销售额，库存应用不断针对物料、工厂、库存地点执行SUM、COUNT一类运算。底层表可能拥有几千万甚至数亿条记录，而最终返回给 ABAP 应用层的结果却可能只有几十行。Dynamic Cache 要解决的正是这种矛盾。它并不是传统意义上的 ABAP Application Server 缓存，也不是大家熟悉的 SAP Table Buffer。它发生在 SAP HANA 数据库这一侧，而且直接参与 SQL Optimizer 的执行计划选择。ABAP 程序仍然可以像平常一样访问原来的 DDIC Database Table，并不需要把SELECT改成读取某张特殊缓存表，也不要求业务代码知道缓存对象的物理名称。真正发生变化的地方隐藏在 SAP HANA 的 SQL 优化阶段。SAP 官方对 ABAP Dynamic Cache 的运行时行为给出了一个非常关键的描述。Dynamic Cache 在 SAP HANA 上会生成一个 SQL View，SAP HANA 可以借助 implicit query matching 判断当前查询是否能够由这个缓存视图满足。一旦成功匹配，SQL Optimizer 可以把执行计划改写成访问 Dynamic Result Cache，而不再扫描原始数据库表。