数据库查询中的存储过程与代码答案

【问题标题】：Stored Procedures vs Code in Database Query数据库查询中的存储过程与代码
【发布时间】：2012-04-18 21:21:32
【问题描述】：

使用 ASP.NET 代码访问数据库与使用 SQL 存储过程进行查询之间的性能差异是什么

为了便于使用，对查询进行编码更容易，尤其是在进行维护和更改时。

但是，存储过程是在数据库中编译并由数据库运行的。

哪个更高效，更好用？

【问题讨论】：

您使用的是什么 DBMS？ Codefile 你的意思是通过 ADO.NET（它也可以调用存储过程）？
我想codefile 表示 ASP.NET 代码隐藏。
@EsotericScreenName：在这种情况下，codefile 和 codebehind 没有区别，但是 OP 没有提到他想如何访问 dbms(NHibernate,Entity Framework, LINQ-to-SQL, ADO.NET , ...)。这更加令人困惑，因为您可以从“codebehind/codefile”调用存储过程。所以根本不清楚他想比较什么。
@TimSchmelter - 我的评论是对可能含义的一般猜测，而不是对您的回应。 There's no difference between codefile and codebehind in this case - 这取决于“代码文件”的含义。 but OP hasn't mentioned how he want to access the dabase(NHibernate,Entity Framework, ADO.NET, ...) - ...和？这与我的评论没有任何关系。 This is even more confusing because you can call stored-procedures from "codebehind/codefile". So it's not clear at all what he wants to compare. 同意，这很令人困惑。
ASP.net codebehind/codefile 不管他们叫什么，我都在谈论一个使用 SQLCommand 准备好的语句。将其与触发存储过程进行比较。您显然必须从代码文件中调用存储过程，但它是在查询数据库时更好地使用，但不要担心有些人已经很好地回答了我的问题，所以我的问题必须足够清晰！

标签： c# asp.net sql stored-procedures

【解决方案1】：

SQL Server 缓存任何查询的执行计划，无论是否 SPROC。这里几乎没有区别。基本上，在使用存储过程时，您无需通过网络发送查询文本，仅此而已。来源：http://msdn.microsoft.com/en-us/library/ms181055.aspx

在没有特殊原因的情况下，做任何对你来说更方便的事情。

其他表明存储过程通常性能更好的答案是不正确的。

【讨论】：

你怎么知道 OP 使用 SQL Server？我不了解 SQL Server，但存储过程比针对特定情况的查询要快（我试过）。
我猜是因为他用的是asp.net。对于 SQL Server，我可以向您保证，情况就是如此。无论如何，为什么 sprocs 会更快？唯一的原因可能是计划缓存，这两种情况都相同 (msdn.microsoft.com/en-us/library/ms181055.aspx)
例如对于非常大的查询或计算内容的查询，因此您可以避免延迟。
延迟仅用于发送查询文本。而已。您可以像使用 SSMS 一样发送整个批次。不是一个查询，而是一个字符串中的任意多个查询。
仅当查询都相互独立时。如果我调用一个获取数据的查询并基于该数据启动查询 3 或查询 4（或其他），那么每个新查询都会有延迟。在存储过程中不是这样。

【解决方案2】：

只要它是一个以数据库为中心的查询，那么存储过程在大多数情况下都是更快的选择（性能）。

但它更难维护，因为它不在您的常规源包中。

“更好用”取决于要求。如果查询稍微慢一点（比如 1 毫秒 VS 3 毫秒）时还可以，那么请将您的代码放在一起并将其放在 ASP 中。如果您希望将性能放在数据库中。

我将大部分查询放在代码中，并且只将那些需要数据库性能的查询放在了代码中。

当然，这也取决于所使用的数据库系统。

【讨论】：

【解决方案3】：

关于您实际比较的内容，您的问题非常不完整。

无论 SQL 代码是在存储过程中还是在客户端提交的完整的内联 SQL 语句中，通常对性能影响不大（假设正确的参数化并且 SQL 是非病态的）。它可以在安全体系结构和需要授予基表或视图的访问权而不是过程的执行权方面产生很大的不同。存储过程鼓励将参数化作为一项要求，但也可以使用内联 SQL 进行参数化。

如果您谈论的是针对从数据库返回的集合执行逻辑还是在数据库中执行工作，这可以是双向的 - 这取决于操作类型、索引类型、客户端和数据库之间的带宽以及需要服务的请求数。

通常，我会首先考虑在数据库中执行此操作，以保持从客户端抽象出来的连接/循环逻辑并减少网络上的数据（列和行）并向客户端提供一个简单的数据集 API，但它取决于。

【讨论】：

【解决方案4】：

这是一个“视情况而定”的问题。
假设这是 SQL Server 2008R2 或更高的标准版或企业版，存储过程的缓存将不同于 TSQL 语句。由于参数化、代码编译、参数嗅探和各种其他优化等多种因素，复杂的 T-SQL 语句几乎总是比存储过程执行得更差。一般来说，我更喜欢存储过程，因为它们更容易优化。此外，您无需重新编译和重新部署任何代码即可更改存储过程。和优化（例如“优化未知数”或当参数值变化很大时，“with recompile”可以应用于存储过程）可以应用于存储过程并且在最终用户甚至没有注意到的情况下撤消（嗯，除了性能变化）。

存储过程在一次运行后总是会在计划缓存中结束，并且永远不会被视为临时查询。根据 SQL 设置，临时查询可能会或可能不会存储在计划缓存中。加上添加或删除字符（假设它未参数化）将导致 SQL Server 构建新计划，而构建新计划是一个缓慢的操作。

TL;DR - 使用 SQL Server 2008R2 或更高版本的标准版/企业版；对于简单的查询，您会发现没有区别。对于复杂的查询，存储过程（如果编写得当）几乎总能胜过 T-SQL。存储过程也更容易在以后进行优化。

编辑 - 在 SQL 版本中添加。我不确定旧的 SQL 版本。

【讨论】：