Snowflake存储过程中：LAST_QUERY_ID()与游标捕获中间结果的最佳实践

两种方案的权衡对比 #

1. RESULT_SCAN(LAST_QUERY_ID()) 方案 #

• 性能表现：几乎无额外开销，Snowflake会缓存最近查询的结果，RESULT_SCAN只是读取这个快照，速度极快。
• 代码维护：一行代码就能实现，非常简洁，但有硬限制——必须保证EXECUTE IMMEDIATE之后没有其他SQL执行。如果中间插入了别的查询，LAST_QUERY_ID()会指向新的查询，导致无法获取正确行数。
• 适用场景：适合逻辑简单的存储过程，DML执行后直接捕获行数，中间无其他操作的场景。

2. 游标方案 #

• 性能表现：相比RESULT_SCAN多了初始化结果集、打开/关闭游标的步骤，存在微小性能损耗，但绝大多数业务场景下可忽略不计。
• 代码维护：代码量稍多，但稳定性更强。不管DML之后有没有其他查询，只要持有Res结果集变量，就能通过游标获取行数，不会因上下文变化出错。同时，熟悉SQL游标的开发者能快速理解逻辑，可读性更好。
• 适用场景：适合复杂存储过程，DML之后还要执行日志记录、分支判断等操作的场景，可避免上下文被覆盖的风险。

选择建议 #

• 若存储过程逻辑简单，DML执行后直接捕获行数，优先用RESULT_SCAN，简洁高效。
• 若存储过程逻辑复杂，DML之后还有其他SQL操作，建议用游标方案，稳定性更高。

补充说明：Snowflake的INSERT/UPDATE/DELETE默认会返回受影响的行数，两种方案都能正确捕获该数值，无需额外配置。

内容的提问来源于stack exchange，提问作者Tharun