Почему LINQ отправляет sp_executesql вместо непосредственного выполнения SQL?

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

РЕДАКТИРОВАТЬ, упс я сказал парамтеризацию вместо замены параметров, спасибо stephbu

sp_executesql предпочтительнее, чем execute, потому что он поддерживает подстановку параметров и имеет тенденцию работать более эффективно.

Answer 3

Это, по крайней мере, частично, так что вы можете повторно использовать план запроса. Параметры могут быть встроены, что означает, что каждый раз, когда вы запускаете запрос с разными параметрами, анализатор видит его как другой запрос и анализирует его. Но поскольку он выполняется таким образом, план запроса кэшируется, и он может просто подключать новые переменные каждый раз, когда вы его запускаете.

Answer 4

Я не думаю, что это решение для производительности. Планы выполнения в SQL кэшируются даже для прямых запросов.

Я думаю, что это решение безопасности для инъекций SQL.

Однако, если вы попытаетесь использовать трассировки, которые используют Linq to SQL в помощнике по настройке ядра СУБД, sp_execute не будет интерпретироваться помощником по настройке, я бы хотел отключить его. Внедрение SQL также может быть обнаружено в инструкциях / инфраструктуре Linq To Sql (код), зачем вам даже пытаться отправлять недопустимые данные в SQL.

Answer 5

Следует отметить, что он также обеспечивает защиту от SQL-инъекций из-за параметризации. Не могу пожаловаться на это...

Answer 6

Это большой вопрос.
На самом деле это не ответ, а исследование причин, уже приведенных в других ответах. Не стесняйтесь обновлять этот "ответ"

Очевидный ответ был бы "parameterized query cacheMsgstr "Однако параметры можно было так же легко связать, когда оператор выполнялся напрямую, и все еще кэшироваться.

Синтаксис и детали в этой статье MSDN...

msdn_microsoft_ms175580

Заявления о производительности Я сомневаюсь в отсутствии данных, поскольку кэш-память одинакова как для прямых, так и для sp_execsql'd запросов.

Так что, если это не так - что это?