多个SQL调用哪个更快 - 参数化查询或存储过程？

Question

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

哪会给我带来更好的表现？为什么？

Answer 1

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

从性能角度来看，它们几乎完全相同。

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

许多公司仍然将“Everything as proc”规则，但这通常是由于数据库的控制而与性能无关。随着LINQ的普及，这可能会减少。

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

Answer 2

很难肯定地说，有很多因素可以影响表现。理论上，存储过程方法应该更快。

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

Answer 3

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

Answer 4

存储过程通常是要走的路。这说明它还取决于你的处理程序的编写程度。尝试在您的存储过程中运行执行计划，以确保您获得最好的收益。此外，如果SQL实例与代码不在同一个框中，则使用存储过程通常是更安全的方式以及服务器上的最佳性能。当您使用存储过程时，您将工作的负载放在SQL框中，这将在存储过程中为您优化查询。

Answer 5

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

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

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

Answer 6

通常是存储过程，因为服务器可以预先优化执行计划。虽然编写良好的参数化查询优于过度通用的存储过程。