Omitiré el argumento de inyección de SQL, que es demasiado conocido y solo me centraré en el aspecto SQL de los parámetros frente a los no parámetros.
Cuando envía un lote de SQL al servidor, cualquier lote, debe analizarse para comprenderlo. Como cualquier otro compilador, el compilador de SQL tiene que producir un AST del texto y luego operar en el árbol de sintaxis. En última instancia, el optimizador transforma el árbol de sintaxis en un árbol de ejecución y finalmente produce un plan de ejecución que realmente se ejecuta. En la edad oscura de alrededor de 1995, marcaba la diferencia si el lote era una consulta Ad-Hoc o un procedimiento almacenado, pero hoy en día no hace absolutamente nada, todos son iguales.
Ahora, donde los parámetros marcan la diferencia es que un cliente que envía una consulta como select * from table where primary_key = @pk enviará exactamente el mismo texto SQL cada vez, no importa en qué valor esté interesado. Lo que sucede entonces es que el todo proceso que describí anteriormente está en cortocircuito. SQL buscará en la memoria un plan de ejecución para el texto sin analizar y sin procesar. recibió (basado en un resumen hash de la entrada) y, si lo encuentra, ejecutará ese plan. Eso significa que no hay análisis, no hay optimización, nada, el lote va directamente a la ejecución . En los sistemas OLTP que ejecutan cientos y miles de pequeñas solicitudes cada segundo, esta ruta rápida marca una gran diferencia en el rendimiento.
Si envía la consulta en el formulario select * from table where primary_key = 1 entonces SQL tendrá que al menos analizarlo para comprender qué hay dentro del texto, ya que es probable que el texto sea nuevo, diferente de cualquier lote anterior que haya visto (incluso un solo carácter como 1 contra 2 hace que todo el lote sea diferente). Luego operará en el árbol de sintaxis resultante e intentará un proceso llamado Parametrización simple . Si la consulta se puede parametrizar automáticamente, es probable que SQL encuentre un plan de ejecución en caché para ella de otras consultas que se ejecutaron anteriormente con otros valores de pk y reutilice ese plan, por lo que al menos no es necesario optimizar su consulta y omitir el paso de generar un plan de ejecución real. Pero de ninguna manera lograste el cortocircuito completo, la ruta más corta posible que logras con una consulta parametrizada de cliente real.
Puede consultar el SQL Server, SQL Statistics Object
contador de rendimiento de su servidor. El contador Auto-Param Attempts/sec mostrará muchas veces por segundo que SQL tiene que traducir una consulta recibida sin parámetros en una con parámetros automáticos. Cada intento se puede evitar si parametriza correctamente la consulta en el cliente. Si también tiene una gran cantidad de Failed Auto-Params/sec es aún peor, significa que las consultas están pasando por el ciclo completo de optimización y generación del plan de ejecución.
