存储过程的大小是否会影响其执行性能？

Question

存储过程的大小是否会影响其执行性能？

对于性能而言，拥有一个完成所有流程的大型SP或将其拆分为多个SP是否更好？

Answer 1

让我解释一下：“我的功能大小会影响它的执行性能吗？”

显而易见的答案是：否。该功能将在它碰巧运行的硬件上尽可能快地运行。 （需要说明的是：当然，较长的功能需要更长时间执行。但它不会运行更慢。因此，性能不受影响。）

正确的问题是：“我编写函数的方式会影响它的执行性能吗？”

答案是：是的，无论如何。

如果您实际上是在问第二个问题，那么您应该添加一个代码示例并更具体。

Answer 2

不，不是真的 - 或者说不是很多。存储过程在服务器上进行了预编译 - 并且它不是在服务器和客户端之间来回发送 - 因此它的大小实际上并非完全相关。

以可维护且易于阅读的方式设置它更为重要。

马克

Answer 3

不确定存储过程的SIZE是什么意思（代码行？，复杂性？表的数量？连接数？）但执行性能完全取决于定义和编译的SQL的执行计划。存储过程。如果您使用的是SQL Server，可以通过SQL事件探查器很好地监视这一点。性能最重要的是连接和表扫描等问题，一个好的工具可以帮助您找出索引的放置位置，或者考虑更好的方法来定义SQL。希望这会有所帮助。

Answer 4

如果执行计划需要刷新以回收本地内存而单个过程不需要，则可能会因编写多个存储过程而导致性能下降。

我们遇到了需要再次刷新存储过程并且必须重新编译的情况。查询访问数百个分区表的视图时，这可能代价高昂，并导致生产中出现超时。从八个结合成两个解决了这个问题。

另一方面，我们有一个非常复杂的存储过程，将其分解为多个允许查询执行计划对于块更简单并且执行得更好。

基本上“依赖于”的其他答案已经死了。无论你有多快的数据库，一个糟糕的查询都会让它瘫痪。每种情况都是独一无二的。在大多数地方，以模块化且易于理解的方式进行编码，性能更好，维护成本更低。 SQL Server必须“理解”它，因为它构建了查询计划。