在 SAP HANA 的项目里，存储过程真正进入运行阶段时，开发人员最终都会碰到同一个动作，CALL。表面上看，调用一个 Procedure 很简单。数据库里已经存在一个存储过程，我们给它传入参数，HANA 执行过程体，再把标量结果或者表结果返回出来。可一旦系统进入高并发生产环境，CALL的写法就不再只是语法风格问题。输入参数究竟直接写成常量，还是通过参数绑定传入，会直接影响 SQL 编译、SQL Plan Cache、执行计划复用、缓存占用以及 CPU 消耗。SAP 在当前的 SAP HANA Platform 2.0 SPS 08 文档中依然明确推荐使用参数化的CALL。官方给出的理由非常直接，参数化调用可以降低重复编译成本，SQL Plan Cache 中保存的语句更加通用，同一个 Procedure 在输入参数发生变化时仍然有机会复用已经生成的执行计划。相反，如果调用时不断把不同常量直接拼进 SQL 文本，系统可能持续产生新的查询计划。理解这一点，需要先把 Procedure Call 从一次普通的方法调用中抽离出来。在 Java、ABAP、Node.js 或其他应用程序中调用一个普通函数，我们很容易形成一种直觉，函数代码已经存在，因此每次调用只需要跳到函数入口执行即可。SAP HANA Procedure 并不是完全按照这种模型工作的。CALL本身同样是数据库需要处理的 SQL 语句。SAP HANA Cloud 当前的 SQLScript Processing Overview 对这条执行链路描述得相当清楚。客户端提交CALL后，