Siempre se recomienda al escribir consultas o código de base de datos de SQL Server (procedimientos y vistas) para tomar nota del plan de ejecución. Hay varias razones para esto. En primer lugar, el optimizador podría estar eligiendo un plan que no espera. Por ejemplo, escanear el índice de una tabla grande antes de hacer coincidir con una tabla más pequeña. En segundo lugar, se debe tener en cuenta cómo funcionará esta consulta en los próximos meses o años si las consultas se ejecutan en un nuevo sistema con tablas pequeñas que crecerán. Y, por último, pero lo más importante, qué tan rápida es esta consulta y cuántos recursos utiliza. Es posible que el último punto no parezca tan importante, tal vez esté pensando que mientras tarde menos de 3 segundos es lo suficientemente bueno, pero si pudiera ejecutarse en <1 segundo, ¿no sería mejor? Si sus bases de datos están alojadas en la nube, reducir los recursos también podría ahorrarle dinero.
Muchos casos de optimización de SQL normalmente provienen de un problema detectado por el usuario final o su software de monitoreo. "¿Por qué este informe tarda 30 minutos en generarse?", "¿Qué está causando ese aumento en la espera de E/S" o "¿Por qué estos trabajos tardan el doble en ejecutarse que el año pasado?"
En todos estos escenarios, todavía se trata de algún conocimiento sobre los planes de ejecución y la mejor manera de corregir el SQL para mejorar la situación y esto puede llevar mucho tiempo y no siempre tener éxito.
Tomemos un ejemplo. Por lo tanto, está escribiendo una nueva consulta, ejecutándola y luego pensando, Dios mío, esto está tardando demasiado.
17 segundos para 730 filas, ¿qué debo hacer?
Primero, revisemos el plan de ejecución:
Esto no siempre es sencillo si tiene que acercar y alejar para que tenga sentido. Por lo tanto, el primer consejo es obtener un buen visor de planos como este con Spotlight Tuning Pack.
El visor del plan resalta los fragmentos de información clave que necesitamos y dónde están las operaciones principales, además de resaltar las advertencias.
Aquí hay un ejemplo:
Entonces, hay un problema con este código, pero ¿qué podemos hacer al respecto?
Bueno, en realidad bastante. Podríamos usar sugerencias de consulta, agregar algunos índices (no olvide que esto podría afectar otras consultas y DML), agregar fragmentos de código que no cambien el conjunto de resultados pero que influyan en el optimizador para generar un plan diferente y pequeños trucos para detenga el optimizador considerando un índice particular que está utilizando y tal vez genere un nuevo plan. Pero todo esto es prueba y error y lleva mucho tiempo hacerlo manualmente.
Al agregar la aplicación Spotlight Extensions a SSMS y suscribirnos al Spotlight Tuning Pack, podemos dejar que la función de optimización en el Tuning Pack haga todo el trabajo duro por nosotros.
Es posible que haya notado en la primera captura de pantalla que cuando la función está habilitada, detecta automáticamente que la optimización es posible:
Haga clic en Ver análisis
A continuación, puede hacer clic en el botón Optimizar y el motor del optimizador analizará el código y comenzará a aplicar reglas de reescritura que cambiarán la sintaxis del SQL dando alternativas que proporcionan el mismo conjunto de resultados, y luego las probará para que podamos ver si hay alguna ejecución alternativa. Los planes son más rápidos y por qué. Las reglas se aplican en combinaciones, por lo que las posibles alternativas pueden ser más de 100. Sin embargo, la herramienta solo muestra alternativas que son más rápidas que la original.
Este proceso se ejecuta en segundo plano y le ahorra una gran cantidad de tiempo si intenta hacerlo manualmente.
Y cuando se muestran los resultados, puede comparar las alternativas, ver las diferencias de código, comparar los planes y revisar las estadísticas.
Entonces, regrese a SSMS con mi nueva versión de la consulta y pruébela.
Éxito.
Si se trata de un entorno de desarrollo, es posible que desee considerar vaciar la memoria caché del búfer con DBCC DROPCLEANBUFFERS para probar sus consultas con una memoria caché de búfer fría sin apagar y reiniciar el servidor.
Además, considere agregar SET STATISTICS IO ON a la consulta para obtener más información sobre por qué la sintaxis de la consulta marcó la diferencia:
Originales:
Reescribir:
Y esto también se puede lograr en el Tuning Pack con la función de comparación de estadísticas:
Entonces, con el cambio exitoso y el usuario final satisfecho, pasemos a la siguiente consulta. Al mejorar continuamente el rendimiento de las consultas individuales, mejoramos el rendimiento de la instancia.
