在一个基于 SAP S/4HANA 的系统里，ABAP 程序执行一条 Open SQL，RAP 应用读取一个 CDS View Entity，SAP Fiori Elements 页面发出一个 OData 查询，看上去走的是三条完全不同的技术路线。可只要最终的数据来自 SAP HANA，这些访问迟早都会落到一个共同的问题上，SAP HANA 到底准备怎样执行这条查询。数据库收到的并不是开发人员已经安排好的执行步骤。SQL 描述的是我们想得到什么数据，而不是数据库必须按照什么顺序完成工作。开发人员可以写出JOIN、WHERE、GROUP BY、ORDER BY，却没有直接规定哪张表先访问、过滤条件在哪一层执行、两个数据源采用哪一种 Join Algorithm、中间结果是否需要物化、哪些步骤能够并行，以及最终应该交给哪个 SAP HANA Execution Engine。这些决定主要由 SAP HANA Query Processor 完成。一条 SQL Statement 进入 SAP HANA 之后，可以把整个主干过程理解成下面这条链路。SQL Statement → SQL Plan Cache → SQL Front End → SQL Optimizer → Execution Plan → Execution EngineSAP 官方对 SAP HANA Query Processing 的描述也是沿着这条路径展开。系统会检查 SQL Plan Cache，在没有可复用计划时进入 SQL Front End 完成解析与检