Si bien respeto al remitente, discrepo humildemente con la respuesta proporcionada y no por "razones religiosas". En otras palabras, creo que no hay ninguna instalación que haya proporcionado Microsoft que disminuya la necesidad de orientación para usar los procedimientos almacenados.
Cualquier orientación proporcionada a un desarrollador que favorezca el uso de consultas SQL de texto sin procesar debe estar llena de muchas advertencias, de modo que creo que el consejo más prudente es alentar en gran medida el uso de procedimientos almacenados y desalentar a sus equipos de desarrolladores a participar en la práctica de incrustar sentencias de SQL en el código, o enviar solicitudes de SQL basadas en texto sin formato y sin formato, fuera de los SPROC de SQL (procedimientos almacenados).
Creo que la respuesta simple a la pregunta de por qué usar un SPROC es como supuso el remitente: los SPROC se analizan, optimizan y compilan. Como tal, sus planes de consulta / ejecución se almacenan en caché porque ha guardado una representación estática de una consulta y, normalmente, la variará solo por parámetros, lo que no es cierto en el caso de las instrucciones SQL copiadas / pegadas que probablemente se transformarán de página a página y componente / nivel, y a menudo se varían en la medida en que se pueden especificar diferentes tablas, incluso nombres de bases de datos, de llamada a llamada. Permitiendo este tipo de dinámica ad hocEl envío de SQL disminuye en gran medida la probabilidad de que DB Engine reutilice el plan de consulta para sus declaraciones ad hoc, de acuerdo con algunas reglas muy estrictas. Aquí, hago la distinción entre consultas dinámicas ad hoc (en el espíritu de la pregunta planteada) versus el uso del eficiente Sistema SPROC sp_executesql.
Más específicamente, hay los siguientes componentes:
- Planes de consulta en serie y paralelos que no contienen el contexto del usuario y permiten su reutilización por parte del motor DB
- Contexto de ejecución que permite la reutilización de un plan de consulta por un nuevo usuario con diferentes parámetros de datos.
- Procedimiento de caché que es lo que consulta el motor de base de datos para crear las eficiencias que buscamos.
Cuando se emite una declaración SQL desde una página web, denominada "declaración ad hoc", el motor busca un plan de ejecución existente para manejar la solicitud. Debido a que este es un texto enviado por un usuario, será ingerido, analizado, compilado y ejecutado, si es válido. En este momento recibirá un costo de consulta de cero. El costo de la consulta se usa cuando el motor de base de datos usa su algoritmo para determinar qué planes de ejecución desalojar de la memoria caché.
Las consultas ad hoc reciben un valor de costo de consulta original de cero, por defecto. Tras la posterior ejecución del mismo texto de consulta ad hoc, por otro proceso de usuario (o el mismo), el costo de la consulta actual se restablece al costo de compilación original. Dado que nuestro costo de compilación de consultas ad hoc es cero, esto no es un buen augurio para la posibilidad de reutilización. Obviamente, cero es el número entero menos valorado, pero ¿por qué sería desalojado?
Cuando surgen presiones de memoria, y lo harán si tiene un sitio de uso frecuente, el motor de base de datos utiliza un algoritmo de limpieza para determinar cómo puede recuperar la memoria que está utilizando la caché de procedimientos. Utiliza el costo de la consulta actual para decidir qué planes desalojar. Como puede suponer, los planes con un costo de cero son los primeros en ser desalojados de la memoria caché porque cero significa esencialmente "no hay usuarios actuales o referencias a este plan".
- Nota: Planes de ejecución ad hoc: el costo actual se incrementa por cada proceso de usuario, por el costo de compilación original del plan. Sin embargo, el costo máximo de ningún plan puede ser mayor que su costo de compilación original ... en el caso de consultas ad hoc ... cero. Por lo tanto, se "aumentará" en ese valor ... cero, lo que esencialmente significa que seguirá siendo el plan de menor costo.
Por lo tanto, es bastante probable que dicho plan sea desalojado primero cuando surjan presiones de memoria.
Por lo tanto, si tiene un servidor incorporado con mucha memoria "más allá de sus necesidades", es posible que no experimente este problema con tanta frecuencia como un servidor ocupado que solo tiene memoria "suficiente" para manejar su carga de trabajo. (Lo sentimos, la capacidad de memoria del servidor y la utilización son algo subjetivas / relativas, aunque el algoritmo no lo es).
Ahora, si estoy objetivamente incorrecto sobre uno o más puntos, ciertamente estoy abierto a ser corregido.
Por último, el autor escribió:
"Ahora tenemos una optimización a nivel de declaración, por lo que una consulta correctamente parametrizada proveniente de una aplicación puede aprovechar el mismo plan de ejecución que esa consulta incorporada en un procedimiento almacenado".
Creo que el autor se refiere a la opción "optimizar para cargas de trabajo ad hoc".
Si es así, esta opción permite un proceso de dos pasos que evita enviar inmediatamente el plan de consulta completo a la caché de procedimientos. Solo envía un trozo de consulta más pequeño allí. Si se envía una llamada de consulta exacta al servidor mientras el código auxiliar de consulta todavía está en la caché de procedimientos, el plan completo de ejecución de la consulta se guarda en la caché de procedimientos, en ese momento. Esto ahorra memoria, que durante los incidentes de presión de memoria, puede permitir que el algoritmo de desalojo expulse su código auxiliar con menos frecuencia que un plan de consulta más grande que se almacenó en caché. Nuevamente, esto depende de la memoria y la utilización de su servidor.
Sin embargo, debe activar esta opción, ya que está desactivada de forma predeterminada.
Por último, quiero enfatizar que, a menudo, la razón por la cual los desarrolladores incrustarían SQL en páginas, componentes y otros lugares, es porque desean ser flexibles y enviar consultas SQL dinámicas al motor de la base de datos. Por lo tanto, en un caso de uso del mundo real, es poco probable que se envíe el mismo texto, llamada sobre llamada, al igual que el almacenamiento en caché / eficiencia que buscamos, al enviar consultas ad hoc a SQL Server.
Para obtener información adicional, consulte:
https://technet.microsoft.com/en-us/library/ms181055(v=sql.105).aspx
http://sqlmag.com/database-performance-tuning/don-t-fear-dynamic-sql
Mejor
Henry