长期运行事务的存储过程中的性能提升

Question

我有几个长时间运行的报告类型事务需要5-10分钟。通过使用存储过程，我会看到任何性能提升吗？会有意义吗？

每个查询每晚运行一次。

Answer 1

可能不是。存储过程为您提供预编译SQL的优势。如果你的SQL很少被调用，那么这种优势将毫无价值。因此，如果您的SQL很昂贵，因为查询本身很昂贵，那么存储过程将无法获得有意义的性能优势。如果你有非常频繁地调用的查询并且它们自己快速执行，那么它就值得进行过程。

Answer 2

很可能不是。存储过程中的性能提升（如果有的话）（取决于您的用例）是微观中无法显示的类型 - 仅在宏中。

报告类型查询是聚合大量数据的查询，如果是这种情况，无论执行方法如何，它都会很慢。只有索引和/或其他物理数据更改才能使其更快。

请参阅：

Are Stored Procedures more efficient, in general, than inline statements on modern RDBMS's?

Answer 3

简短的回答是：不，存储过程不会改善性能。 首先，如果使用参数化查询，则存储过程和内联SQL之间的性能没有差异。原因是所有查询都缓存了执行计划 - 而不仅仅是存储过程。 看看http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

如果您没有对内联查询进行参数化，并且您只是构建查询并将“参数”作为文字插入，则每个查询看起来与数据库不同，并且需要预编译每个查询。因此，在这种情况下，您可以通过在内联SQL中使用参数来帮助自己。从安全角度来看，无论如何都应该这样做，否则你就是在接受SQL注入攻击。

但无论如何，预编译问题在这里是一个红色的鲱鱼。你在谈论长时间运行的查询 - 只要预先称赞是无关紧要的。所以不幸的是，你不会轻易在这里下车。您的解决方案将是优化查询的实际设计，甚至重新考虑您完成任务的整个方式。

Answer 4

是的，可以优化存储过程的查询计划 即使它不能触发也优于嵌入式sql

“你会看到任何性能提升” - 唯一可以确定的方法是尝试

理论上，存储过程预解析sql并存储查询计划而不是每次都计算出来，因此应该有一些加速，但是，我怀疑它在5-10分钟的过程中会很重要

如果关注速度，最好的办法是查看查询计划，看看是否可以通过不同的查询结构和/或添加索引等来改进

如果速度不受关注，则存储过程提供比内联sql更好的封装

Answer 5

正如其他人所说的那样，预编译的存储过程不会带来太多的性能提升。但是，如果您当前的事务有多个语句，数据在服务器之间来回传递，那么将其包装在存储过程中可能会消除一些来回，这可能是一个真正的性能杀手。

查看正确的索引，但也要考虑查询本身（或整个过程，如果它包含多个步骤）可能效率低下的事实。没有看到你的实际代码，很难说。