在 SAP HANA 数据库中，一条 SQL 查询运行缓慢时，我们通常会检查执行计划，观察数据库选择了怎样的访问路径、连接顺序和计算算子，从而判断性能瓶颈究竟出现在数据访问、过滤、排序还是聚合环节。然而，当性能问题发生在 SQLScript 存储过程内部，事情就没有那么简单了。一个存储过程可能同时包含多条 SQL 语句、局部变量、条件判断、循环、动态 SQL，以及对其他存储过程的调用。某条查询即使拥有合理的执行计划，整个存储过程仍然可能因为循环次数过多、重复执行数据库操作或者过程调用关系复杂而出现性能问题。假设我们的 SAP S/4HANA 系统通过 AMDP 调用一个 HANA 存储过程，完成销售订单的批量计算。这个过程需要读取订单数据、计算折扣、检查客户信用额度，并调用另一个存储过程执行价格计算。如果仅仅分析其中某条SELECT语句的执行计划，我们能够了解这条查询怎样访问数据库，却无法完整观察存储过程内部各个操作之间的关系。此时，SAP HANA 提供的EXPLAIN PLAN for CALL就有了用武之地。它能够针对存储过程调用生成编译计划信息，并将结果写入系统全局临时表EXPLAIN_CALL_PLANS。通过查询该表，我们可以了解 SQLScript 引擎怎样组织存储过程内部的操作，包括条件分支、循环结构以及嵌套存储过程调用等。不过，这里需要明确一个非常重要的区别。EXPLAIN PLAN for CALL展示的是编译计划，而不是一次真实执行过程中采集到的性能跟踪数据。它可以帮助我们理解存储过程的内部
