Question

例如，LINQ to SQL正在发送以下内容：

exec sp_executesql 
N'SELECT [t0].[HomeID], 
  [t0].[Bedrooms], 
  [t0].[ImageURL], 
  [t0].[Price], 
  [t0].[Available], 
  [t0].[Description]
FROM 
  [dbo].[Homes] AS [t0]
WHERE 
  ([t0].[Description] LIKE @p0) AND 
    ([t0].[Available] = @p1) AND 
    ([t0].[Price] >= @p2) AND ([t0].[Price] <= @p3)
ORDER BY 
  [t0].[Price] DESC',
N'@p0 nvarchar(4000),@p1 int,@p2 int,@p3 int',
@p0=N'%private%',
@p1=1,
@p2=200000,
@p3=750000

为什么使用sp_executesql？

Answer 1

此表示法允许运行时编译的TSQL语句与不同的参数一起使用;即该语句只编译一次，以提高效率。

Answer 2

编辑，oops我说的是参数化而不是参数替换，谢谢stephbu

sp_executesql优先于执行，因为它支持参数替换，并且往往更有效地执行。

Answer 3

这至少部分是为了让您重新使用查询计划。它可以将参数设置为内联，这意味着每次使用不同的参数运行查询时，分析器都会将其视为不同的查询并对其进行重新分析。但是由于它以这种方式执行，因此查询计划被缓存，并且每次运行它时都可以插入新变量。

Answer 4

我不认为这是一种性能解决方案。即使对于直接查询，SQL中的执行计划也会被缓存。

我认为它是sql注入的安全解决方案。

但是，如果您尝试在数据库引擎优化顾问中使用使用Linq to SQL的跟踪，则调优顾问不会对sp_execute进行插入，我想将其关闭。也可以在Linq To Sql语句/框架（代码）中检测SQL注入，为什么你甚至会尝试向SQL发送无效数据。

Answer 5

需要注意的一点是，由于参数化，它还提供了SQL Injection的保护。真的不能抱怨那个......

Answer 6

这是一个很好的问题。
这不是真正的答案，而是对其他答案已经给出的推理的探索。随意更新这个“答案”

显而易见的答案是“parameterized query cache”。但是，当语句直接执行时，参数可以很容易地被绑定并且仍然被缓存。

此 MSDN 文章中的语法和详细信息......

msdn_microsoft_ms175580

性能声明我怀疑没有数据，因为直接和sp_execsql'd查询的缓存似乎相同。

所以，如果不是那些 - 它是什么？

为什么LINQ发送sp_executesql而不是直接执行SQL？

6 个答案: