¿Cómo se arreglan las consultas que solo se ejecutan lentamente hasta que se guardan en caché?

Question

Tengo algunas consultas que están causando tiempos de espera en nuestro entorno en vivo. (> 30 segundos)

Si ejecuto el generador de perfiles y tomo el SQL exacto que se está ejecutando y lo ejecuto desde Management Studio, tardan mucho tiempo en ejecutarse por primera vez y luego caen en cientos de milisegundos cada vez que se ejecuta.

Obviamente, SQL almacena en caché los datos y los guarda todo en la memoria.

Estoy seguro de que hay optimizaciones que se pueden realizar en el SQL que lo harán funcionar más rápido.

Mi pregunta es, ¿cómo puedo "corregir" estas consultas cuando, la segunda vez que lo ejecuto, los datos ya se almacenaron en caché y son rápidos?

Answer 1

Según http://morten.lyhr.dk/2007/10/how-to-clear-sql-server-query-cache.html, puede ejecutar lo siguiente para borrar la memoria caché:

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE 

EDIT: he comprobado con la documentación de SQL Server que tengo y esto es cierto al menos para SQL Server 2000.

Answer 2

La optimización de consultas es un tema extenso, no hay una sola respuesta a su pregunta. Las pistas sobre qué hacer están todas en el plan de consulta, que deberían ser las mismas independientemente de si los resultados están en caché o no.

Busque lo habitual, como escaneos de tabla, índices que no se utilizan cuando espera que se utilicen, etc. etc. En última instancia, es posible que tenga que revisar su modelo de datos y quizás implementar una estrategia de desnormalización.

Answer 3

De MSDN:
"Utilice DBCC DROPCLEANBUFFERS para probar consultas con una caché de tampón frío sin necesidad de apagar y reiniciar el servidor"

Answer 4

Uso puede utilizar

DBCC DROPCLEANBUFFERS 
DBCC FREEPROCCACHE 

Pero sólo utilizar esto en su entorno de desarrollo, mientras que la sintonía de las consultas para la implementación en un servidor en vivo.

Answer 5

Le sugiero que inspeccione el plan de ejecución para las consultas que son responsables de sus problemas de rendimiento.

Debe identificar, dentro del plan de ejecución, qué pasos son los más costosos y por qué. Podría ser que sus consultas estén realizando un escaneo de tabla, o que un índice inapropiado se esté utilizando, por ejemplo.

Hay un ebook muy detallado y gratuito disponible en el sitio web de RedGate que se concentra específicamente en la comprensión del contenido de los planes de ejecución.

https://www.red-gate.com/Dynamic/Downloads/DownloadForm.aspx?download=ebook1

Usted puede encontrar que hay un plan de ejecución particular que le gustaría que se utilizará para su búsqueda. Puede forzar qué plan de ejecución se utiliza para una consulta en SQL Server mediante sugerencias de consulta. Sin embargo, este es un concepto bastante avanzado y debe usarse con discreción. Consulte el siguiente White Paper de Microsoft para obtener más detalles.

http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspx

Asimismo, no recomendaría que se borre la caché de procedimientos en su entorno de producción, ya que será perjudicial para el rendimiento de todas las demás averiguaciones sobre la plataforma que no están actualmente experimentan problemas de rendimiento.

Si está ejecutando un procedimiento almacenado, por ejemplo, puede asegurarse de que se calcula un nuevo plan de ejecución para cada ejecución del procedimiento utilizando el comando WITH RECOMPILE.

Para obtener información general sobre el ajuste del rendimiento, hay algunos recursos excelentes en el blog de Brent Ozar.

http://www.brentozar.com/sql-server-performance-tuning/

Espero que esto ayude. Aclamaciones.

Answer 6

Creo que la gente está corriendo en la dirección incorrecta. Si lo entiendo, ¿quieres que el rendimiento sea bueno todo el tiempo? ¿No están corriendo rápido el segundo (y las ejecuciones posteriores) y son lentos la primera vez?

Los comandos DBCC anteriores borran la memoria caché, causando un rendimiento PEOR.

Lo que quiere, creo, es preparar la bomba y almacenar en caché los datos. Puede hacer esto con algunos procedimientos de inicio que ejecutan las consultas y cargan datos en la memoria.

La memoria es un recurso finito, por lo que no puede cargar todos los datos, probablemente, en la memoria, pero puede encontrar un equilibrio. Brent tiene algunas buenas referencias más arriba para ayudarlo a aprender lo que puede hacer aquí.