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

Question

我在这里有一个很好的问题。

使用ASP.NET CODEFILE访问数据库与使用SQL STORED PROCEDURE进行查询之间有什么性能差异

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

然而，存储过程在数据库中编译并由数据库运行！

哪一个更有效，更好用？

Answer 1

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

没有特殊理由存在，做对你更方便的事情。

其他答案表明，对于sprocs来说，通常性能更好是不正确的。

Answer 2

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

但是它很难维护，因为它不在你的常规源包中。

“更好地使用”取决于要求。如果它的查询速度稍慢（例如1 ms VS 3 ms），那么将代码放在一起并将其保存在ASP中。如果你希望将性能放在数据库中。

我将大部分查询都放在代码中，而只放在数据库中需要执行的那些查询。

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

Answer 3

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

SQL代码是在存储过程中还是从客户端提交的完整内联SQL语句通常对性能没什么影响（假设适当的参数化和SQL是非病态的）。它可以在安全体系结构和基本表或视图所需的访问权限上产生很大的差异，而不是在程序上执行权限。存储过程鼓励参数化作为一项要求，但内联SQL也可以进行参数化。

如果您正在讨论针对从数据库返回的集合执行逻辑而不是在数据库中执行工作，则可以采用两种方式 - 这取决于操作类型，索引类型，客户端和数据库之间的带宽以及需要提供服务的请求数量。

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

Answer 4

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

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

TL; DR - 预先构建SQL Server 2008R2或更高版本的Standard / Enterprise;对于简单的查询，您会发现没有区别。对于复杂查询，存储过程（如果正确编写）几乎总是执行T-SQL。存储过程也可以在以后更容易优化。

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