使用 SQL Analyzer 在 SAP HANA Cloud 中比较参数化查询计划

背景：参数化查询与性能波动

参数化查询在不同输入值下运行速度差异巨大，通常是因为数据分布倾斜。优化器为每个语句编译一个计划，该计划可能对小选择性范围最优，但对大范围则效果不佳。例如，一个接受区域参数的表函数，在区域为 DE 时可能在 20 毫秒内返回 50 行，而区域为 GLOBAL 时则需 4 秒返回 200 万行。这种差异并非一定是查询 Bug，而通常是依赖于选择性的计划选择。首要步骤是捕获每组参数集的执行计划，并使用 SQL Analyzer 进行对比，以决定波动是否由计划选择引起，以及启用计划变体或重写查询是否为正确的解决方案。

SQL Analyzer 是一组视图、表和图表，允许分析任何 SQL 查询。用户可以深入研究图表执行情况，分析查询编译和执行的时间线，可视化所用表，查看每步处理的记录数并检查操作符序列。它不仅限于计算视图，还能分析表函数和 SQL 控制台中的语句。使用前提是在开发空间添加 SAP HANA Performance Tools 扩展（仅在开发空间停止时可操作），且用户需拥有 TRACE ADMIN 和 INIFILE ADMIN 系统权限。工作流是从 SQL 控制台开始，通过 Analyze Generate SQL Analyzer Plan File 生成计划文件，最后在 HANA SQL Analyzer 视图中打开该文件。

计划文件可通过嵌入式 SAP HANA Database Explorer 生成并直接打开，或通过外部工具生成后下载并上传至 SAP Business Application Studio 的 Explorer 视图。生成文件的位置是固定的。若需后续分析，可通过 Explorer 视图或外部数据库资源管理器的特定诊断文件路径访问。关键点在于，每个需要对比的参数值都必须拥有独立的计划文件，单一的缓存计划无法应对选择性变化。

对比应集中在步骤级执行时间、处理记录数和操作符序列上。执行时间显著增加或处理记录数远超预期的步骤即为瓶颈。操作符序列揭示了优化器是否选择了不同的连接顺序、访问路径或处理引擎。如果慢速参数值的计划不同，可以通过启用计划变体让 HANA 根据过滤选择性集群缓存多个计划，或者重写查询并重构模型，使优化器在所有选择性范围内产生稳定计划。这取决于优化器能否区分选择性集群以及查询结构是否根本高效。

计划变体允许 SAP HANA 根据表过滤的选择性为参数化查询缓存多个执行计划。优化器评估谓词，编译计划，并将过滤值与集群关联，从而减少性能波动。然而，这仅在优化器能将参数值分组为不同选择性集群时有效。如果查询结构对所有输入都低效，或优化器无法区分集群，仅靠计划管理无法解决问题，此时必须重写查询或重构模型。

可以通过 M_SQL_PLAN_VARIANTS 和 M_SQL_PLAN_VARIANT_STATISTICS 监控视图来检查活跃的计划变体及其执行统计数据。这些视图有助于验证优化器是否创建了预期的集群以及计划是否被使用，从而衡量性能提升情况。重写决策应基于计划文件的证据，而非对数据分布的假设。

具体示例：一个接受区域参数的表函数。DE 区域 20 毫秒返回 50 行，GLOBAL 区域 4 秒返回 200 万行。在 SQL 控制台中分别调用这两个参数并生成两个计划文件，在 SQL Analyzer 中并排对比。观察发现，对于 GLOBAL，优化器选择了全列存扫描和嵌套循环连接，而 DE 则使用了索引查找加哈希连接。这证实了计划随参数值而异，建议启用计划变体或重写连接顺序和过滤下推。

SELECT * FROM TABLE(TABLE_FUNCTION(:region)) WHERE region = :region;

推理：计划变体与查询重写

参数化查询通常缓存单个执行计划，但这往往是一种折中方案。当过滤选择性改变时，最优计划也会随之改变。如果优化器无法区分选择性集群，可能会选择一个对某些值有效但对其他值低效的计划，这是 SQL 性能波动的根源。计划变体通过允许缓存多个计划来解决此问题，使系统能为小选择性范围和大选择性范围分别保留不同的计划。

仅缓存一个计划的局限性在于无法适应数据分布的变化。对小结果集最优的计划（如使用嵌套循环连接）在处理大结果集时可能极其低效。计划变体通过为每个选择性集群创建独立计划来解决此问题，优化器根据参数值所属集群选择相应计划，从而确保性能稳定。通过 M_SQL_PLAN_VARIANTS 等监控视图可以验证集群创建是否正确。

然而，计划变体并非万能。它仅在优化器能区分选择性集群时有效。如果查询结构本身低效，或者优化器无法将参数值分离到不同集群，计划管理无法提升性能。此时唯一的选择是重写查询或重构模型，例如改变连接顺序、增强过滤下推或用更高效的结构替换表函数。决策应基于 SQL Analyzer 的计划文件。

整体工作流为：为每个参数值生成计划文件 -> 在 SQL Analyzer 中对比 -> 决定使用计划变体还是重写。如果计划文件显示操作符序列、记录数或时间不同，说明优化器已在区分参数值，此时启用计划变体可减少波动。如果计划相同但特定值运行慢，说明优化器未区分集群，则需要重写。

核心区别在于计划管理与查询结构。计划变体管理多个计划，但不能修复结构低效的问题。如果优化器无法区分集群或数据倾斜极端，必须重写查询。SQL Analyzer 的证据应引导决策：如果计划稳定但对特定值缓慢，则是结构问题；如果计划不同且大选择性范围选择了慢计划，则计划变体可能足够。

监控视图提供了决策所需的证据。M_SQL_PLAN_VARIANTS 显示活跃变体，M_SQL_PLAN_VARIANT_STATISTICS 显示执行统计。这很重要，因为计划变体会增加开销，需确认收益大于成本。重写决策应基于计划文件和监控视图，而非假设。

再次以区域参数为例：DE 快速，GLOBAL 慢。通过 SQL Analyzer 对比发现 GLOBAL 使用了全扫描和嵌套循环连接，而 DE 使用了索引查找和哈希连接。这证明了计划随参数变化，从而引导开发者选择启用计划变体或重写连接顺序以实现全范围稳定性。

SELECT * FROM M_SQL_PLAN_VARIANTS WHERE SCHEMA_NAME = '<container_schema_name>' AND OBJECT_NAME = '<calculation_view_or_function>';

具体演示：在 SQL Analyzer 中对比计划文件

工作流始于在 SQL 控制台中输入参数化 SQL。无需执行查询，只需通过 Analyze Generate SQL Analyzer Plan File 菜单选项生成计划文件并保存。如果使用嵌入式 SAP HANA Database Explorer，文件会直接在 SQL Analyzer 视图中打开；若使用外部工具，则需手动下载并上传至 SAP Business Application Studio。前提是开发空间必须在停止状态下安装 SAP HANA Performance Tools 扩展。

上传计划文件后，在主窗口中显示结果。SQL Analyzer 以图表形式展示执行计划，包含步骤级执行时间、处理记录数和操作符序列。用户可以钻取执行图，分析编译与执行时间线，并可视化表的使用情况。目标是识别执行时间异常长的步骤、记录数远超预期的步骤以及在不同参数值之间存在差异的操作符序列，这些都是选择性依赖计划选择的迹象。

在具体示例中，为 DE 和 GLOBAL 区域分别生成计划文件并并排对比。DE 的计划应显示索引查找和哈希连接，处理记录数较少；GLOBAL 的计划应显示全列存扫描和嵌套循环连接，处理记录数巨大。步骤级时间和记录数将证实这种差异，证明优化器为慢速参数选择了不同计划，从而确定需要计划变体或重写。

对比重点应放在操作符序列上，因为它揭示了连接顺序、访问路径或处理引擎的变化。用全列存扫描代替索引查找是选择性不匹配的常见信号，嵌套循环连接代替哈希连接亦然。每步处理的记录数揭示了数据量，如果本应处理数十行却处理了数百万行，该步骤即为瓶颈。时间线则有助于判断延迟是在编译阶段、执行阶段还是特定操作符中。

对比后决定方案：若计划文件显示不同计划且优化器能区分集群，则启用计划变体；若计划相同但特定值缓慢，则需重写。通过 M_SQL_PLAN_VARIANTS 等视图验证计划变体是否活跃且统计数据是否符合预期选择性集群。

总结示例：DE 区域 20ms/50行，GLOBAL 区域 4s/200万行。通过 SQL Analyzer 观察到 GLOBAL 采用了全扫描和嵌套循环连接，而 DE 采用了索引查找和哈希连接。这证实了计划随参数值而异，建议通过计划变体缓存两种计划，或重写连接顺序和过滤下推以确保稳定性。

EXPLAIN PLAN FOR SELECT * FROM TABLE(TABLE_FUNCTION(:region)) WHERE region = :region;

适用性限制

SQL Analyzer 依赖于开发空间中的 SAP HANA Performance Tools 扩展，且该扩展仅能在开发空间停止时添加。这是启动工作流前必须验证的前提。分析用户需要 TRACE ADMIN 和 INIFILE ADMIN 系统权限，由于这些是系统级权限，生产环境中的应用用户可能无法获得，导致部分用户无法使用此工作流。此外，非嵌入式 Explorer 生成的文件需手动上传，且文件保存位置固定，增加了操作步骤。

计划变体仅在优化器能将参数值分组为不同选择性集群时有效，无法修复结构性低效的查询。如果优化器无法区分集群或数据倾斜极端，仅靠计划管理无法解决问题，必须重写查询或重构模型。虽然 M_SQL_PLAN_VARIANTS 等视图能验证集群创建情况，但它们不能改变底层的查询结构。

启用计划变体还是重写查询的决策应基于计划文件的证据。如果计划文件显示不同计划且集群可区分，则计划变体可减少波动；如果计划相同但特定值慢，则必须重写。监控视图提供决策证据，但不能替代对查询和数据分布的深入理解。

再次回顾示例：DE 区域与 GLOBAL 区域的性能差异。通过 SQL Analyzer 发现 GLOBAL 触发了全扫描和嵌套循环连接，而 DE 使用了索引查找和哈希连接。这证明了计划随参数值而异，从而引导开发者在启用计划变体（缓存两种计划）或重写连接顺序（实现全范围稳定计划）之间做出选择。

SELECT * FROM M_SQL_PLAN_VARIANTS WHERE SCHEMA_NAME = '<container_schema_name>' AND OBJECT_NAME = '<calculation_view_or_function>';