在本地部署的 SAP HANA 和 SAP HANA Cloud 场景里，SQL 性能问题往往不是“缺一个索引”这么简单。你会遇到更棘手的情况：同一条 SQL 在测试环境飞快，上线后忽快忽慢；某次数据量增长之后，报表从 3 秒变成 3 分钟；明明写了过滤条件，却像没生效一样把全表扫描了一遍。这类问题真正的突破口，通常藏在两份看起来“短小精悍”、却信息密度极高的输出里：Optimized Logical Plan和Optimized Physical Plan。它们来自代价优化阶段的最终产物，前者给出“这棵树长什么样”，后者告诉你“这棵树的叶子到底是哪种、由哪个引擎来摘、怎么摘”。理解它们，你就等于拿到了 SAP HANA 优化器的“决策摘要”，后续无论是用 Plan Visualizer、Explain Plan、SQL Trace 还是 Performance Trace，都能更快把分析焦点收敛到关键点上。为什么这两份 Plan 能成为排障的“总览地图”很多同学分析慢 SQL 时容易陷入两个极端：只看 Explain Plan：能看到算子树，但缺少运行时细节，容易停留在“看起来合理”。只看执行期 Trace：细节爆炸，信息量太大，反而抓不住主线。Optimized Logical Plan和Optimized Physical Plan恰好夹在中间：足够抽象，能让你在 30 秒内形成全局印象；又足够具体，能解释“为什么会长成这样”。从官方定义