2009-07-01 12 views
7

Para eaxmple, LINQ a SQL está enviando el siguiente:¿Por qué LINQ envía sp_executesql en lugar de ejecutar directamente el 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 

¿Por qué se utiliza sp_executesql?

+0

OP debe aclarar un poco lo que quiere decir, supongo que está mirando a través del Analizador de SQL y ver las llamadas que fluyen. Interpreto su pregunta como "por qué L2S usa sp_executesql en lugar de enviar las declaraciones contenidas directamente". – stephbu

Respuesta

11

Esta notación permite la declaración TSQL tiempo de ejecución compilado para ser reutilizado con diferentes parámetros; es decir, la declaración solo se compila una vez, lo que mejora la eficiencia.

+1

Ejecutar utiliza la misma memoria caché de declaración con consultas parametrizadas. – stephbu

+1

Además, de esta manera es más seguro contra la inyección de SQL. – gerleim

4

EDITAR, oops ¿He dicho paramterization en lugar de reemplazo de parámetros, gracias stephbu

sp_executesql es preferible a ejecutar, ya que apoya la sustitución de parámetros, y tiende a llevar a cabo de manera más eficiente.

+1

La ejecución es igual de parametrizable, por lo que la parametrización no lo es. ¿Qué datos dicen que funciona de manera más eficiente? Tiene al menos el mismo costo. – stephbu

+0

Pudo haber sido más correcto desde el punto de vista técnico decir la sustitución de parámetros en lugar de la parametrización, en cuanto a la eficacia que invito a consultar en el siguiente enlace. http://msdn.microsoft.com/en-us/library/ms175170.aspx – cmsjr

+0

http://msdn.microsoft.com/en-us/library/ms175580.aspx como información adicional sobre Execute que admite el mismo almacenamiento en caché parametrizado estrategias. – stephbu

4

Esto es, al menos parcialmente, de manera que se obtiene consulta reutilización del plan. Podría poner los parámetros en línea, lo que significa que cada vez que ejecute la consulta con diferentes parámetros, el analizador la verá como una consulta diferente y la reparará. Pero dado que se ejecuta de esta manera, el plan de consulta se almacena en caché y puede simplemente agregar las nuevas variables cada vez que lo ejecute.

0

Una cosa a tener en cuenta es que también proporciona protección contra SQL Injection causa de parametrización. realmente no puede quejarse de que uno ...

+0

No según este enlace: http://msdn.microsoft.com/en-us/library/ms188001.aspx - "Las instrucciones de ejecución de Transact-SQL compiladas en el tiempo pueden exponer las aplicaciones a ataques maliciosos, como la inyección SQL". – Adamski

+0

Esta no es una razón para usar sp_executesql tho '. La parametrización está disponible en las llamadas SqlExecDirect a través de OLE/DB y ODBC también. – stephbu

+0

@Adamski - por supuesto que sí. Http://msdn.microsoft.com/en-us/library/bb386929.aspx. "LINQ to SQL evita tal inyección mediante el uso de SqlParameter en las consultas". – jinsungy

0

Esta es una gran pregunta.
Esto no es realmente una respuesta sino una exploración del razonamiento ya dado por otras respuestas. No dude en actualizar esta "respuesta"

La respuesta obvia habría sido "parameterized query cache". Sin embargo, los parámetros podrían vincularse tan fácilmente cuando la instrucción se ejecutó directamente y aún se almacenan en caché.

sintaxis y los detalles en este MSDN artículo ...

msdn_microsoft_ms175580

demandas de rendimiento y sin dudo de datos desde la memoria caché parece ser el mismo para ambas consultas directas e sp_execsql'd.

Entonces, si no es eso, ¿qué es eso?

2

No creo que sea una solución de rendimiento. Los planes de ejecución en SQL se almacenan en caché incluso para consultas directas.

yo creo que es una solución de seguridad para la inyección de SQL.

Sin embargo, si intenta utilizar trazas que usan Linq en SQL en el Asistente de optimización del motor de base de datos, el asesor de ajuste no interpreta el comando sp_execute, me gustaría desactivarlo. La inyección de SQL también se puede detectar en las sentencias/marco de Linq To Sql (el código), por qué intentarás enviar datos inválidos a SQL.

Cuestiones relacionadas