为什么存储过程比查询快

Question

我想写一个简单的单行查询，从数据库中只选择一个值。

因此，如果我为这个查询编写存储过程，而不是用c#代码编写简单的select查询，那么我确信这个简单的select查询的存储过程会更快，但是为什么呢？

我对存储过程和在我的代码中编写简单查询感到困惑？我搞不懂为什么存储过程比直接用代码编写的简单查询快？

Answer 1

存储过程比SQL代码更快

这是一个神话，性能总是等同的，从书中：Architecting Microsoft® .NET Solutions for the Enterprise:

SQL是一种语言，您可以通过它来声明您对要在数据库上执行的操作(查询、更新或管理操作)的意图。数据库引擎得到的所有内容都是文本。与编译器处理的SQL源文件非常相似，C#源代码必须以某种方式进行编译，以生成一系列较低级别的数据库操作--此输出以执行计划的名称命名。从概念上讲，执行计划的生成可以看作是编译程序的数据库对应部分。

据称，与普通SQL代码相比，存储过程保证的性能提升在于对执行计划的重用。换句话说，当您第一次执行SP时，DBMS会生成执行计划，然后执行代码。下一次，它将重用之前生成的计划，从而更快地执行命令。所有SQL命令都需要一个执行计划。

错误的说法是DBMS只对存储过程重用执行计划。就SQL Server和Oracle DBMS而言，重用执行计划的好处适用于任何SQL语句。引用自SQL Server 2005联机文档：

在SQL Server2005中执行任何SQL语句时，关系引擎首先检查过程缓存，以验证同一SQL语句的现有执行计划是否存在。SQL Server2005重新使用它找到的任何现有计划，从而节省了重新编译SQL语句的开销。如果不存在现有执行计划，SQL Server2005将为查询生成新的执行计划。

围绕SP比普通SQL代码性能更好的争论是毫无意义的。在性能方面，命中数据库的任何SQL代码都以同样的方式处理。编译后的性能是相同的。句号。

Answer 2

"Stored procedures are precompiled and cached so the performance is much better."

这对我来说是令人心碎的，就像您在SQL Server2005年之前才知道这是真的一样。本文打破了Stored Procedures DO NOT increase performance 的迷思

微软公司的克里斯塔·卡彭蒂埃撰写了An Evaluation of Stored Procedures for the .NET Developer

Answer 3

这取决于查询，对于简单的查询，最好将其作为查询本身编写和执行。但是，当您在数据库端有更多的处理要做时(您希望获取游标中的数据、对其进行操作等等)，存储过程会更好，因为它们在数据库服务器上执行，并避免了不必要的开销，如解析和额外的通信。