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

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

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

其他表明 sprocs 性能通常更好的答案是不正确的。

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

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

"更好用"取决于要求。如果查询速度稍慢（例如 1 毫秒与 3 毫秒）没问题，请将代码放在一起并将其放在 ASP 中。如果性能是您想要的东西，请将其放入数据库中。

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

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

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

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

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

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

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

存储过程在单次运行后将始终位于计划缓存中，并且永远不会被视为即席查询。 即席查询（取决于 SQL 设置）可能会也可能不会存储在计划缓存中。 此外，添加或删除字符（假设它未参数化）将导致 SQL Server 生成新计划，并且构建新计划的操作很慢。

TL;DR - 预用 SQL Server 2008R2 或更高版本的标准/企业版;对于简单的查询，您不会注意到任何区别。 对于复杂查询，存储过程（如果编写正确）几乎总是无法执行 T-SQL。 存储过程在以后也更容易优化。

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