我有一个简单的语句，在子句SELECT中引用了几列。WHERE通常我在 VB 代码中执行这些简单的操作（设置 Command 对象，将 Command Type 设置为文本，将 Command Text 设置为 Select 语句）。但是我看到了超时问题。我们已经对我们的表格等进行了优化。
我想知道是否会因为我以这种方式进行查询而对性能产生很大影响，而不是创建一个带有几个参数的简单存储过程。我在想也许内联代码会强制 SQL 进行额外的编译、创建查询计划等工作，如果我使用存储过程就不会发生这种情况。
正在运行的实际 SQL 的示例：
SELECT TOP 1 * FROM MyTable WHERE Field1 = @Field1 ORDER BY ID DESC
格式良好的“内联”或“临时”SQL 查询——如果与参数一起正确使用——与存储过程一样好。
但这绝对是至关重要的：您必须使用正确的参数化查询！如果你不这样做 - 如果你将每个请求的 SQL 连接在一起 - 那么你就不会从这些点中受益......
就像存储过程一样，在第一次执行时，必须找到一个查询执行计划 - 然后将该执行计划缓存在计划缓存中 - 就像存储过程一样。
如果您多次调用内联参数化 SQL 语句，则该查询计划会一遍又一遍地重用 - 并且“内联”SQL 查询计划受制于与存储过程的执行计划相同的缓存逐出策略。
从这个角度来看——如果你真的使用了正确的参数化查询——存储过程没有性能优势。
存储过程还有其他好处（比如作为“安全边界”等），但只是原始性能并不是它们的主要优点之一。
确实，数据库必须做你提到的额外工作，但这不应该导致很大的性能损失（除非你非常非常频繁地运行查询......）
使用 sql profiler 查看实际发送到服务器的内容。使用活动监视器查看是否有其他查询阻止您的查询。
您的查询再简单不过了。Field1 是否已编入索引？正如其他人所说，“临时”查询不会影响性能。
对于在哪里提出疑问，这是科技界最古老的辩论之一。我认为您的请求“属于”您的应用程序。它们将与您的应用程序一起进行版本控制，使用您的应用程序进行测试，并在您的应用程序消失时消失。将它们放在您的应用程序以外的任何地方都是一个痛苦的世界。但看在上帝的份上，请使用 .sql 文件，编译为嵌入式资源。
作为任何其他语句的表单子句的一部分的选择语句称为内联查询。不能带参数。不是数据库对象
过程：可以带参数 如果需要执行相同的操作，可以全局使用数据库对象。