我有一些长时间运行的报表类型事务，这些事务需要5到10分钟。通过使用存储的proc，我会看到性能提升吗？这会很重要吗？

每个查询每晚运行一次。

解决方案

是的，可以优化存储过程的查询计划
并且即使它不能procs也比嵌入式sql更可取

"我们会看到任何性能改进吗"，唯一可以确定的方法就是尝试一下

从理论上讲，存储过程会预先解析sql并存储查询计划，而不是每次都进行计算，因此应该从中获得一些提速，但是，我怀疑这在5到10分钟的过程中是否有意义

如果担心速度，最好的办法是查看查询计划，看看是否可以通过使用不同的查询结构和/或者添加索引等方法来提高查询速度。

如果不关心速度，则存储的proc比内联sql提供更好的封装

可能不是。存储的procs为我们提供了预编译SQL的优势。如果SQL很少被调用，那么它们的这种优势将毫无价值。因此，如果SQL昂贵，因为查询本身也很昂贵，那么存储的proc将不会给我们带来有意义的性能优势。如果查询被频繁调用并且快速执行，那么值得使用proc。

很有可能不会。从存储的过程获得的性能提升(如果有的话)(取决于用例)是在微-仅在宏中不明显的那种。

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

看：

通常，存储过程是否比现代RDBMS上的内联语句更有效？

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

考虑适当的索引编制，但还要考虑以下事实：查询本身(或者整个过程(包括多个步骤)可能效率很低)。没有看到实际代码，很难说。

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

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

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