EXECUTE ('CALL SCHEMA.PROC')、CALL SCHEMA.PROC 和 EXECUTE 之间是否存在性能差异答案

【问题标题】：Is there a performance difference between EXECUTE ('CALL SCHEMA.PROC'), CALL SCHEMA.PROC, and EXCEUTEEXECUTE ('CALL SCHEMA.PROC')、CALL SCHEMA.PROC 和 EXECUTE 之间是否存在性能差异
【发布时间】：2020-02-20 08:42:14
【问题描述】：

假设以下查询结构，这三个选项之间是否存在性能差异：

CREATE PROCEDURE SCHEMA.PROC
BEGIN
TEMP = SELECT * FROM A JOIN B JOIN C;
INSERT INTO TABLE (TEMP);
END;

选项 1：

STRING_OF_PROC = 'CALL SCHEMA.PROC()';

EXECUTE IMMEDIATE (STRING_OF_PROC);

选项 2：

CALL SCHEMA.PROC();

选项 3：

EXECUTE IMMEDIATE ( TEMP = SELECT * FROM A JOIN B JOIN C; 
                    INSERT INTO TABLE (TEMP); );

如果不同的 RDBMS 之间存在差异，我在 SAP HANA 领域工作。

【问题讨论】：

标签： sql stored-procedures query-optimization dynamic-sql hana

【解决方案1】：

好的，这个问题相当模糊，所以我的回答将仅描述不同的选项以及由此产生的内容。

选项 0：这是一个执行 SELECT 并尝试将结果插入到表中的存储过程。

选项 1：准备一个包含 CALL procedure() 文本的字符串，然后将该字符串用于动态 SQL 执行 EXECUTE IMMEDIATE。

选项2：直接调用过程。

选项 3：带有 SQLScript 命令块的 EXECUTE IMMEDIATE 调用。

广告选项 3 根本不起作用并导致错误，因为 EXECUTE IMMEDIATE 需要一个命令 字符串。这个命令字符串需要是正确的 SQL，这里不是这样。此外，它只能是单个命令，而不是多个命令的列表。

作为选项 1 和 2：从性能的角度来看，它们几乎相同。显然，动态 SQL 选项需要额外的解析，并且可能会导致共享 SQL 缓存中的额外条目，但这应该是整个过程调用运行时可以忽略不计的一部分。

顺便说一句：选项 0 中的过程也不起作用 - 该过程在几个地方的语法错误。

底线：动态 SQL 调用和直接调用不带参数或返回值的单个过程的调用在性能上的差异可能可以忽略不计。

【讨论】：