使用 ASP.NET 代码访问数据库与使用 SQL 存储过程进行查询之间的性能差异是什么
为了便于使用，对查询进行编码更容易，尤其是在进行维护和更改时。
但是，存储过程在数据库中编译并由数据库运行。
哪一种更高效，更好用？
问问题
2828 次
4 回答
4
SQL Server 缓存任何查询的执行计划，无论是否 SPROC。这里几乎没有区别。基本上，在使用存储过程时，您无需通过网络发送查询文本，仅此而已。来源：http: //msdn.microsoft.com/en-us/library/ms181055.aspx
在没有特殊原因的情况下，做任何对你来说更方便的事情。
其他表明存储过程通常具有更好性能的答案是不正确的。
于 2012-04-18T21:34:58.533 回答
2
只要它是一个以数据库为中心的查询，那么存储过程在大多数情况下将是更快的选择（性能）。
但它更难维护，因为它不在您的常规源包中。
“更好用”取决于要求。如果当查询稍微慢一点（比如 1 毫秒 VS 3 毫秒）时它还可以，那么将您的代码放在一起并将其放在 ASP 中。如果性能是您想要将其放入数据库中的东西。
我将大部分查询放入代码中，并且仅将那些需要数据库性能的查询放入其中。
当然，这也取决于使用的数据库系统。
于 2012-04-18T21:28:08.523 回答
0
关于您实际比较的内容，您的问题非常不完整。
SQL 代码是在存储过程中还是在从客户端提交的完整的内联 SQL 语句中通常对性能影响不大（假设参数化正确且 SQL 是非病态的）。它可以在安全体系结构和需要授予基表或视图的访问权而不是过程的执行权方面产生很大的不同。存储过程鼓励将参数化作为一项要求，但也可以使用内联 SQL 进行参数化。
如果您谈论的是针对从数据库返回的集合执行逻辑而不是在数据库中执行工作，这可以是双向的——这取决于操作的类型、索引的类型、客户端和数据库之间的带宽以及请求的数量需要维修。
通常，我会首先在数据库中进行操作，以保持连接/循环逻辑从客户端抽象出来并减少网络上的数据（列和行）并向客户端提供一个简单的数据集 API，但它取决于.
于 2012-04-18T21:43:50.077 回答
0
这是一个“取决于”的问题。
假设这是 SQL Server 2008R2 或更高的标准版或企业版，存储过程的缓存将不同于 TSQL 语句。由于参数化、代码编译、参数嗅探和各种其他优化等多种因素，复杂的 T-SQL 语句几乎总是比存储过程执行得更差。一般来说，我更喜欢存储过程，因为它们更容易优化。此外，您无需重新编译和重新部署任何代码即可更改存储过程。并且优化（例如“优化未知”或“重新编译”可以应用于存储过程，当参数值变化很大时）可以应用于存储过程并且在最终用户甚至没有注意到的情况下撤消（嗯，
存储过程在一次运行后总是会在计划缓存中结束，并且永远不会被视为临时查询。根据 SQL 设置，临时查询可能会或可能不会存储在计划缓存中。加上添加或删除一个字符（假设它没有参数化）将导致 SQL Server 构建一个新计划并且构建新计划是一个缓慢的操作。
TL;DR - preusming SQL Server 2008R2 或更高版本的标准版/企业版；对于简单的查询，您会发现没有区别。对于复杂的查询，存储过程（如果编写得当）几乎总能胜过 T-SQL。存储过程也更容易在以后进行优化。
编辑 - 在 SQL 版本中添加。我不确定旧的 SQL 版本。
于 2017-02-06T16:10:23.307 回答