为什么存储过程比Query快

Question

为什么存储过程比Query快

Amm*_*aja 39 c# sql sql-server stored-procedures

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

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

我对存储过程与在我的代码中编写简单查询感到困惑？我很困惑,为什么存储过程比直接在代码中编写的简单一个查询更快？

Answer 1

cuo*_*gle 79

存储过程比SQL代码快

这是一个神话,性能总是等同于本书: 为企业架构Microsoft®.NET解决方案:

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

存储过程保证优于普通SQL代码的所谓性能提升在于重用执行计划.换句话说,第一次执行SP时,DBMS会生成执行计划,然后执行代码.下次它将重用以前生成的计划,从而更快地执行命令.所有SQL命令都需要执行计划.

(错误)神话是DBMS仅对存储过程重用执行计划.就SQL Server和Oracle DBMS而言,重用执行计划的好处适用于任何SQL语句.引用SQL Server 2005在线文档:

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

围绕SP执行比普通SQL代码更好的争论毫无意义.从表面上看,任何命中数据库的SQL代码都以相同的方式处理.编译后,性能相当.期.

@muhammadkashif:这是日期,SP是从10年前开始,趋势是使用ORM在代码中动态生成SQL.SP很难维护,想想如何在SQL代码中调试,真的很痛苦 (3认同)
你想到了我.需要从你的角度再次研究它.谢谢你的不同观点. (2认同)
好吧，通常普通的 SQL 语句会命中缓存，并且与存储过程一样快。但这如何转化为不经常执行的非常复杂的查询呢？这些是否可能会错过缓存，并且它们仍然可以从存储过程中受益吗？或者存储过程从一开始就从未真正预编译过，并且这些过程是否使用与常规查询完全相同的缓存？ (2认同)

Answer 2

Tah*_*667 5

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

Run Code Online (Sandbox Code Playgroud)

这让我心碎，当您在 SQL Server 2005 之前知道这是真的时，您也会感到心碎。本文打破了“存储过程不会提高性能”的神话

Microsoft 公司的 Christa Carpentiere撰写了《针对 .NET 开发人员的存储过程评估》

归档时间：	12 年，10 月前
查看次数：	27337 次
最近记录：	6 年前