存储过程与原始查询的效率

Question

我在这场辩论的双方都阅读了很多内容：仅使用存储过程而不是原始查询是否会显着提高性能？我对 SQL Server 特别感兴趣，但对任何和所有数据库都感兴趣。

Answer 1

在 SQL Server 2008 及更高版本中不那么重要，但它仍然存在。归根结底是执行计划缓存和 SQL Server 能够自动参数化发送的查询。当使用存储过程（其中没有动态 SQL）时，查询已经参数化，因此 SQL Server 不会“运行时不需要为每个查询生成计划，因为计划已经存储在计划缓存中。

并且不要忘记使用存储过程时会消失的安全问题（动态 SQL、最小权限等）。

当应用程序对基表使用动态 SQL 来选择、插入、更新和删除表中的数据时，应用程序需要直接拥有对所有这些对象的权限。因此，如果有人使用 SQL 注入进入服务器，他们将有权查询、更改或删除这些表中的所有数据。

如果您正在使用存储过程，他们只有执行存储过程的权限才能返回存储过程将返回的信息。他们需要弄清楚可以使用哪些程序来删除数据，然后弄清楚如何使用该程序来执行此操作，而不是发出快速删除语句并清除所有内容。

鉴于 SQL 注入是闯入数据库的最简单方法，这很重要。

Answer 2

作为 Denny 答案的补充，发现在单个或低使用率的临时执行计划上浪费了大量缓冲池内存的系统并不少见，这些执行计划是由于在 procs 上使用查询而创建的。

最近最坏的情况是，8GB 分配给一个实例，3GB 计划缓存，2.5GB 单次使用计划。其中大部分是 SQL2005，因此无法尝试针对临时工作负载设置进行优化。

将性能包含在原始查询的过程的理由中当然变得越来越困难。现在对我来说最有力的论点之一是“如果您使用过程，那么在出现性能问题时我会更容易提供帮助”。动态/linq/orm 接口不会阻止您进行调整，但它会严重限制您的选择。

Answer 3

SQL Server 以相同的方式缓存和优化存储过程和即席 SQL。例如，这个过程：

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

将被优化和缓存相同：

select * from Orders where id = @id

但是，由于硬编码值，以下临时 SQL 无法有效缓存：

select * from Orders where id = 42

尽管性能相同，但使用存储过程是有充分理由的。存储过程明确区分了 DBA 和应用程序开发人员。在您的宝贵数据和不断变化的程序之间有一层额外的防御是很好的:)