内联 SQL 与存储过程答案

【问题标题】：Inline SQL versus stored procedure内联 SQL 与存储过程
【发布时间】：2012-08-18 01:17:05
【问题描述】：

我有一个简单的SELECT 语句，在WHERE 子句中引用了几列。通常我在 VB 代码中执行这些简单的操作（设置命令对象，将命令类型设置为文本，将命令文本设置为 Select 语句）。但是我看到了超时问题。我们已经对我们的表格等进行了优化。

我想知道是否会因为我以这种方式进行查询而对性能造成很大影响，而不是使用几个参数创建一个简单的存储过程。我在想也许内联代码会强制 SQL 进行额外的编译、创建查询计划等工作，如果我使用存储过程就不会发生这种情况。

实际运行的 SQL 示例：

SELECT TOP 1 * FROM MyTable WHERE Field1 = @Field1 ORDER BY ID DESC

【问题讨论】：

发布代码将有助于回答问题。
Ad hoc queries vs stored procedures vs Dynamic SQL的可能重复
无论你做什么，在你的sql中使用参数！真正检查性能瓶颈的唯一方法是分析您的查询，但从参数化 sql 开始，无论是通过内联 sql 还是存储过程，都是一个好的开始。
SELECT TOP 1 * FROM MyTable WHERE Field1 = @Field1 ORDER BY ID DESC（ID 是身份种子第一列）
执行计划是什么样的？ Field1 是否已编入索引？您是否会遇到并发数据修改语句的阻塞？

【解决方案1】：

格式良好的“内联”或“临时”SQL 查询——如果与参数一起使用——与存储过程一样好。

但这绝对至关重要：您必须使用正确的参数化查询！如果您不这样做 - 如果您将每个请求的 SQL 连接在一起 - 那么您不会从这些要点中受益......

就像存储过程一样，在第一次执行时，必须找到一个查询执行计划 - 然后将该执行计划缓存在计划缓存中 - 就像存储过程一样。

如果您多次调用内联参数化 SQL 语句，则该查询计划会被一遍又一遍地重复使用 - 并且“内联”SQL 查询计划受制于与存储过程的执行计划相同的缓存逐出策略。

仅从这个角度来看 - 如果您确实使用正确的参数化查询 - 存储过程不会带来性能优势。

存储过程还有其他好处（例如作为“安全边界”等），但只是原始性能并不是它们的主要优点之一。

【讨论】：

【解决方案2】：

确实，数据库必须完成您提到的额外工作，但这不应导致性能大幅下降（除非您非常非常频繁地运行查询......）

使用 sql profiler 查看实际发送到服务器的内容。使用活动监视器查看是否有其他查询阻止了您的查询。

【讨论】：

【解决方案3】：

您的查询再简单不过了。 Field1 是否已编入索引？正如其他人所说，“临时”查询不会影响性能。

关于在哪里提出疑问，这是科技界最古老的争论之一。我认为您的请求“属于”您的应用程序。它们将与您的应用程序一起进行版本控制，使用您的应用程序进行测试，并且在您的应用程序消失时消失。将它们放在您的应用程序以外的任何地方都是一个痛苦的世界。但看在上帝的份上，请使用 .sql 文件，编译为嵌入式资源。

【讨论】：

【解决方案4】：

Select 语句，它是任何表单子句的一部分另一个语句称为内联查询。不能带参数。不是数据库对象

程序：可以带参数数据库对象如果需要执行相同的操作，可以全局使用。

【讨论】：