¿Qué factores pueden causar la recompilación de procedimientos almacenados en SQL Server?

Question

¿Qué factores debo tener en cuenta que pueden causar una recompilación excesiva del procedimiento almacenado?

Serán útiles algunos ejemplos del código que provocará que un procedimiento almacenado recompile. El objetivo sería evitar una recompilación si es posible, lo que debería mejorar el rendimiento.

El SQL dinámico y las rutas variables que dan como resultado salidas diferentes (por tipo de datos y/o número de columnas) parecen que podrían presentar un problema. Son las suposiciones correctas? ¿Hay otros ejemplos?

Editar: Encontré otro ejemplo. Crear una tabla temporal en una declaración de control de flujo provocará una recompilación.

Answer 1

Hay algunas maneras de asegurar la recompilación de un procedimiento almacenado:

• usando WITH RECOMPILE,
• haciendo que el procedimiento almacenado dinámico (piensa exec())
• marcando el proc de recompilación con sp_recompile.
• cambiar el esquema de que un plan de consulta almacenado en caché se basa en
• llamando DBCC FREEPROCCACHE
• A nivel de consulta una declaración individual dentro de un proc puede volver a compilar con la sugerencia de consulta RECOMPILE (SQL 2008).

Factores en la Recopilación

Además de las duras factores mencionados anteriormente, lo que hace que recompilación del procedimiento almacenado? Bueno, muchas cosas. Algunos de estos están entretejidos con la lista anterior, pero quiero volver a presentarlos b/c, puede que no sea obvio.

• inserción o eliminación de una gran cantidad de datos (densidad de datos en los índices & tablas menudo controla los planes de consulta)
• volver a generar índices (un cambio a los objetos subyacentes)
• crear/eliminar tablas temporales (de nuevo, que generan cambios DML)
• edades plan de consulta fuera (no creo utilizados recientemente y sql quieren de para limpiar el uso de memoria)

Esto es de ninguna manera una lista exhaustiva. El optimizador de consultas evoluciona y sorprende sin importar cuánto tiempo haya estado usando SQL Server. Pero aquí hay algunos recursos que pueden ser de utilidad:

• Troubleshooting stored procedure recompilation (un viejo, pero bueno)
• Recompling Stored Procedures
• Optimizing SQL Server Stored Procedures to Avoid Recompiles
• Execution Plan Caching and Reuse (una lectura obligada)

PERO ESPERA HAY MAS !

Dicho esto, la presunción en su pregunta es que las recompilaciones siempre son malas para el rendimiento. De hecho, a menudo la recompliación es buena.

¿Cuándo le gustaría recompilar? Veamos un ejemplo de un proceso que busca por apellido. Los procedimientos almacenados hacen 'parameter sniffing', lo cual es una bendición (si le sirve) y una maldición (si funciona en su contra). Primer pase alguien busca en Zebr% para zerbrowski. El índice de apellidos se da cuenta de que esto es muy específico y devolverá, digamos, 3 filas de un millón, por lo que se genera un plan de ejecución. Con el procedimiento compilado para un resultado de fila baja, la siguiente búsqueda es para S%. Bueno, S es su nombre más común y coincide 93.543 filas de 1 millón.

Answer 2

¡Algunas opciones de SET pueden provocar la recompilación de procedimientos almacenados o incluso varias recompilaciones en una sola ejecución!

Algunas de estas opciones pueden ser ni siquiera dentro de la SP

--this will cause recompilation 
SET concat_null_yields_null ON; 
EXEC spMyProc; 

Algunas de las opciones que causan recompilación cuando están dentro del SP:

ARITHABORT

ANSI_NULLS

QUOTED

Afortunadamente, esto o ne no causa la recompilación: SET NOCOUNT ON;