多个 SQL 调用（参数化查询或存储过程）哪个更快？答案

【问题标题】：Which is faster for multiple SQL calls - parameterized queries or stored procedures?多个 SQL 调用（参数化查询或存储过程）哪个更快？
【发布时间】：2009-04-06 21:48:48
【问题描述】：

我正在使用 SQL Server 2005。我正在考虑打开 SQL 连接、循环通过集合并使用来自集合项的数据运行更新查询（存储过程或参数化查询），然后关闭连接。

哪个可以给我更好的性能，为什么？

【问题讨论】：

标签： c# sql-server sql-server-2005 ado.net

【解决方案1】：

在最新版本的 SQL Server 中，为存储过程和参数化查询缓存了执行计划。查询将有一次创建执行计划的成本，但这将非常小，甚至会在几次调用的开销中丢失。

从性能的角度来看，它们几乎是相同的。

例外情况是，如果您正在执行递归或嵌套查询（对于查询 1 中的每一行，执行查询 2），客户端和服务器之间的往返行程将累加。在这种情况下，proc 会好很多。

许多公司仍然有“Everything as a proc”规则，但这通常是由于对数据库的控制而不是性能相关。随着 LINQ 越来越受欢迎，这种情况可能会减少。

如果您的应用程序有一个（或几个）部署点，则使用您喜欢的任何一个。另一方面，如果您要部署到许多安装，那么存储过程可以在某些（但不是全部）情况下允许您更新数据库功能而无需重新部署客户端代码。

【讨论】：

【解决方案2】：

很难肯定地说，因为有许多因素会影响性能。理论上存储过程方法应该更快。

还有另一种解决方案，您可以将 XML 传递给存储过程，这样您就不必多次调用它。假设您可以并且知道如何将您的对象序列化为 XML。然后，您可以使用 Xquery、Open XML 或 sp_XML_preparedocument 以基于集合的方式从 XML 中检索数据并执行更新语句。

【讨论】：

所以基本上它就像一个批量插入？

【解决方案3】：

这通常会变成程序员和 DBA 之间的宗教辩论。许多程序员倾向于喜欢预准备语句方法，因为它允许他们完全控制正在执行的查询，而 DBA 出于同样的原因喜欢存储过程方法。如果您在公司的开发人员和 DBA 之间没有明确的界限，并且您同时涉足开发和 DBA 角色，那么我可能会更倾向于存储过程路线，因为如果您将来需要对查询进行细微更改微调性能或修复错误，然后您不必重新编译和重新部署您的应用程序。

【讨论】：

【解决方案4】：

存储过程通常是要走的路。也就是说，它还取决于您的 proc 编写的好坏。尝试在您的存储过程上运行执行计划，以确保您物有所值。此外，如果 SQL 实例与您的代码不在同一个盒子上，那么使用存储过程通常是更安全的方式以及服务器上的最佳性能。当您使用存储过程时，您将工作负载放在 SQL 框上，这将为您在存储过程中优化查询。

【讨论】：

+1 表示关于安全性的评论。公开存储过程时，您可以将这些 SProcs 上的 EXECUTE 授予您的用户；如果您使用参数化查询，它们需要对基础表进行读/写访问。

【解决方案5】：

使用直接查询或存储过程在性能（如果有的话）上没有太大差异，但如果您使用不同的数据反复运行相同的查询，则绝对应该使用参数。

使用Prepare方法确保重复使用相同的执行计划：

使用查询/过程创建SqlCommand 对象。
创建具有指定数据类型但没有值的SqlParameter 对象，并将它们添加到命令的Parameters 集合中。
在命令对象上调用Prepare 方法。
循环遍历刚刚设置参数值的数据并执行命令。

【讨论】：

【解决方案6】：

通常是存储过程，因为服务器可以预先优化执行计划。尽管编写良好的参数化查询比过于笼统的存储过程要好。

【讨论】：