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

Question

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

每个查询每晚运行一次。

score 5 · Accepted Answer

可能不是。存储过程为您提供了预编译 SQL 的优势。如果你的 SQL 被不频繁地调用，那么这个优势将毫无价值。因此，如果您的 SQL 很昂贵，因为查询本身很昂贵，那么存储过程将不会为您带来任何有意义的性能优势。如果您有非常频繁地调用并且本身执行速度很快的查询，那么值得拥有一个 proc。

score 4 · Accepted Answer

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

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

看：

score 3 · Accepted Answer

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

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

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

score 1 · Accepted Answer

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

“你会看到任何性能改进吗” - 确定的唯一方法是尝试它

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

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

如果速度不是问题，存储过程提供比内联 sql 更好的封装

score 1 · Accepted Answer

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

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

5 回答 5