Solución:
Esto es principalmente una preferencia debido a la seguridad y la coherencia, y no tiene nada que ver con el rendimiento (aunque eso puede haber sido más preocupante en las versiones antiguas de SQL Server).
Por que usar EXEC() algunas veces cuando deberías usar sp_executesql siempre que tenga parámetros? EXEC() lo obliga a concatenar todas sus variables en una sola cadena, y esto lo hace propicio para el abuso.
Escribí sobre esto con más detalle aquí:
- Malos hábitos para patear: usar EXEC () en lugar de sp_executesql
También escribí sobre protegerse de la inyección de SQL aquí:
- Protéjase de la inyección de SQL en SQL Server – Parte 1
- Protéjase de la inyección de SQL en SQL Server – Parte 2
La inyección de SQL es un gran problema, y muchas otras personas también han escrito al respecto.
Finalmente, cuando llame a los procedimientos del sistema, asegúrese de usar la carcasa adecuada para que coincida con lo que está almacenado en sys.all_objects – debe ser todo en minúsculas. De lo contrario, si su código se implementa en una instancia sensible a mayúsculas y minúsculas, todo comenzará a fallar.
En primer lugar, veamos qué significan ambos comandos:
sp_executesql: Ejecuta una instrucción Transact-SQL o un lote que se puede reutilizar muchas veces, o uno que se ha creado de forma dinámica. La instrucción Transact-SQL o el lote pueden contener parámetros incrustados.
exec: Ejecuta una cadena de comando o una cadena de caracteres dentro de un lote de Transact-SQL, o uno de los siguientes módulos: procedimiento almacenado del sistema, procedimiento almacenado definido por el usuario, procedimiento almacenado CLR (Common Language Runtime), función definida por el usuario con valores escalares o procedimiento almacenado extendido. La instrucción EXECUTE se puede utilizar para enviar comandos de paso a los servidores vinculados.
algunas de las principales faltas:
-
sp_executesqlpermite parametrizar declaraciones, por lo tanto, es más seguro que EXEC en términos de inyección SQL -
sp_executesqlpuede aprovechar los planes de consulta en caché, la cadena TSQL se crea solo una vez, después de eso, cada vez que se llama a la misma consulta consp_executesql, SQL Server recupera el plan de consulta de la caché y lo reutiliza. - Las tablas temporales creadas en EXEC no pueden utilizar el mecanismo de almacenamiento en caché de la tabla temporal.
Referencias:
https://blogs.msdn.microsoft.com/turgays/2013/09/17/exec-vs-sp_executesql/
https://msdn.microsoft.com/en-us/library/ms188001.aspx
https://msdn.microsoft.com/en-us/library/ms188332.aspx
Editar:
Encontré el siguiente artículo sobre la actuación:
El rendimiento es un tema de debate entre estos dos métodos para procedimientos almacenados. Como sugiere su nombre, sp_execute es en sí mismo un procedimiento almacenado, que se almacena en la base de datos del sistema. SP_ExecuteSQL debe requerir pasarle cadenas SQL por lo tanto, excepto para mostrar mayores posibilidades de almacenamiento en caché, lo que conduce a un mejor rendimiento cuando se ejecuta por segunda vez o más tarde.
En otras palabras, su T-SQL dinámico parametrizado fomenta su reutilización. Además, se supone que sp_execute tiene mayores posibilidades de evitar una compilación innecesaria al ejecutar una consulta dinámica sobre exec(). Pero algunos expertos lo toman por engañoso, ya que piensan que para ambos métodos se almacenará en caché un plan. De hecho, para las consultas no parametrizadas de SP_ExecuteSQL muestra las mismas características que la última.
http://www.technovisitors.com/2014/07/SPExecuteSQL-Vs-Execute-SQL-Server.html