使用 DataReader 时，从性能角度来看，执行 SQL 语句还是存储过程更好？答案

【问题标题】：When using DataReader, is it better to execute SQL statements or stored procs from performance viewpoint?使用 DataReader 时，从性能角度来看，执行 SQL 语句还是存储过程更好？
【发布时间】：2012-04-17 15:01:44
【问题描述】：

我需要从与给定ID 匹配的表中检索一些字段。目前，我构建了一个sql语句

SELECT a, b, c 
FROM d 
WHERE id = @id

然后使用DataReader 执行它。

我还可以编写一个以id 作为参数的存储过程。

我想知道哪个对性能更友好。

编辑：我正在使用参数化查询，对问题进行了编辑以反映这一点。

【问题讨论】：

我不认为DataReader 是您要考虑的事情——这个类只是读取查询的结果。我认为如果没有前 3 个字，您的问题会更有意义。
存储过程和正确参数化的查询将执行几乎相同的操作。但在查询中使用 parameters 很重要 - 例如SELECT ... FROM d WHERE ID = @ID 并且您不只是将您的 SQL 语句串在一起。这种做法也会为 SQL 注入攻击打开所有大门——这是一个非常糟糕的主意！

标签： c# sql-server performance stored-procedures ado.net

【解决方案1】：

它们的表现通常几乎相同。

请注意，如果频繁调用它，可能会出现差异；每次发送时都必须解析 SQL 代码（但如果语句被识别为被缓存，则不必重新编译），而 SP 是预编译的，但这会导致索引选择不理想，因为统计信息不会重新每次调用都进行评估。

【讨论】：

SQL Server 将计算临时查询的哈希值并在查询缓存中查找。如果找到该计划，它将不会重新编译甚至解析查询。即席 SQL 查询与索引选择欠佳的存储过程存在完全相同的问题。
如果查询不使用参数，这是正确的，但从提出的问题中我假设要使用参数。 msdn.microsoft.com/en-us/library/ee343986(v=sql.100).aspx
@Lucero 是的，要使用的参数。

【解决方案2】：

现代版本的 SQL Server 在性能方面几乎没有差异。动态构建 SQL 通常被认为是不可以的——你想使用parameterized SQL 来避免 SQL 注入，但它和存储过程通常会提供相同的性能。

【讨论】：

【解决方案3】：

如果你使用prepared statements而不是通过连接字符串构建的sql语句，那么存储过程和prepared statement之间的性能没有区别。两者都是在第一次运行时编译并缓存在 sql server 的查询计划中。

【讨论】：

【解决方案4】：

运行存储过程会更好，1）因为执行计划是提前编译并缓存的，2）您不会将数据库暴露给 sql 注入攻击。如果没有代码示例，就不可能说出您当前的操作方式，但我想您只是创建一个字符串并要求执行它，这将是一个坏主意。

【讨论】：

一个设计合理的带有参数的“ad-hoc”查询与存储过程一样好 - 它编译一次，保存在计划缓存中，重复使用 - 与存储过程相同。
-1 存储过程和 ad-hoc SQL 以相同的方式缓存。使用 ad-hoc SQL 不会导致更多的编译（除非您设置了“针对 ad hoc 工作负载进行优化”服务器选项）