在 SAP S/4HANA 项目里排查性能问题时，一个很容易产生误判的现象是，一条 SQL 看起来极其简单，真正执行数据读取的时间也不算长，但整个请求仍然明显偏慢。继续深入分析后，经常会发现时间并没有主要消耗在数据扫描、Join、Aggregation 或排序阶段，而是花在了 SQL 真正开始执行之前。SAP HANA 把这一部分时间称为 Preparation Time，也经常称为 Compile Time。SAP 官方文档给出的定义很直接，HANA Preparation Time 就是请求执行期间，为其中 SQL Statement 编译 SQL Plan 所花费的时间。在 ABAP Statistics Record 场景下，一个请求里的 HANA Preparation Time 还是该请求所有 SQL Statement Hash 子记录 Preparation Time 的累计值。所以，当我们看到一个 ABAP 请求数据库时间很高时，不能简单地把它理解成数据库读数据很慢。数据库时间内部至少应该区分两个性质完全不同的阶段，一个阶段在研究该怎么执行 SQL，另一个阶段才是真正按照已经确定的执行计划处理数据。Preparation Time 属于前一个阶段。一条 SQL 进入 SAP HANA 之后，并不是数据库看到SELECT就立刻开始扫描 Column Store。SAP HANA 需要先理解 SQL 的语法和语义，需要解析其中涉及的 Table、View、Calculation View、Join、Filter、Aggregation、Expression 等对象，还需要将查询转换成内部结构，再对这些结构进行大量 Rewrite 与 O