在 SAP HANA 性能分析现场，有一种现象非常容易误导开发人员。业务查询最终可能只返回几十行、几百行数据，SQL 本身看上去也没有复杂到离谱，但执行时间却突然从几百毫秒增长到数秒甚至几十秒，内存峰值同时大幅上升。此时如果只盯着最终结果集，很难解释资源到底消耗在了哪里。真正需要看的不是最终返回了多少行，而是 SAP HANA 在得到最终结果之前，内部究竟处理过多少数据。这正是 Query Execution Plan 最有价值的地方。一个 SQL 查询提交给 SAP HANA 之后，并不是按照 SQL 文本从上到下机械执行。SQL Optimizer 会根据表统计信息、谓词选择性、连接关系、数据分布、可用执行引擎、Join 类型以及各种代价估算，构造一个成本更低的物理执行方案。因此，我们在 PlanViz 或 SAP HANA SQL Analyzer 中看到的执行计划，可以理解成 SAP HANA 真正的数据加工流水线。SAP 官方文档把执行计划中的 Operator 描述为查询执行过程中承担具体数据处理任务的执行步骤。Logical Operator 描述需要完成什么逻辑操作，而 Physical Operator 决定这些逻辑操作在底层数据存储和执行引擎中究竟怎样执行。SAP HANA SQL Analyzer 还会展示 Input Rows、Output Rows、CPU Time、Execution Time、Input Size、Output Size 等信息，用来判断数据在哪个节点突然膨胀，以及哪个 Operator 真正消耗了资源。这类分析里最需要警惕的一种执行计划，大致有这样的形态。底部出现一个 Column Search，
在 SAP HANA 性能分析现场，有一种现象非常容易误导开发人员。业务查询最终可能只返回几十行、几百行数据，SQL 本身看上去也没有复杂到离谱，但执行时间却突然从几百毫秒增长到数秒甚至几十秒，内存峰值同时大幅上升。此时如果只盯着最终结果集，很难解释资源到底消耗在了哪里。真正需要看的不是最终返回了多少行，而是 SAP HANA 在得到最终结果之前，内部究竟处理过多少数据。这正是 Query Execution Plan 最有价值的地方。一个 SQL 查询提交给 SAP HANA 之后，并不是按照 SQL 文本从上到下机械执行。SQL Optimizer 会根据表统计信息、谓词选择性、连接关系、数据分布、可用执行引擎、Join 类型以及各种代价估算，构造一个成本更低的物理执行方案。因此，我们在 PlanViz 或 SAP HANA SQL Analyzer 中看到的执行计划，可以理解成 SAP HANA 真正的数据加工流水线。SAP 官方文档把执行计划中的 Operator 描述为查询执行过程中承担具体数据处理任务的执行步骤。Logical Operator 描述需要完成什么逻辑操作，而 Physical Operator 决定这些逻辑操作在底层数据存储和执行引擎中究竟怎样执行。SAP HANA SQL Analyzer 还会展示 Input Rows、Output Rows、CPU Time、Execution Time、Input Size、Output Size 等信息，用来判断数据在哪个节点突然膨胀，以及哪个 Operator 真正消耗了资源。这类分析里最需要警惕的一种执行计划，大致有这样的形态。底部出现一个 Column Search，
