Consulta de ajuste de rendimiento

Cuando termine de escribir una consulta / proceso / función almacenada, ¿cuál es la forma más informativa de obtener rápidamente algunos parámetros de rendimiento? ¿Ejecutas la consulta y ves el plan de ejecución real? Si es así, ¿cuáles son las cosas que buscas? Obviamente, los escaneos de tabla / índice son los golpes de bits, pero ¿qué más?

Para una evaluación rápida, obtenga el plan de ejecución de SSMS y en Plan Explorer .

• Revise las operaciones más caras para cualquier cosa inesperada. Clasificaciones, tablas de trabajo, operadores de unión inapropiados (por ejemplo, bucle anidado donde espera una fusión o hash).
• Mire los recuentos de filas en cada etapa del plan, ¿están dentro del rango que esperaba ver?
• Mire las filas estimadas vs reales. Si sus datos reales están cerca de las estimaciones, es más probable que tenga un buen plan. Si hay grandes variaciones, averigüe por qué (estadísticas faltantes y / o desactualizadas, por ejemplo).
• Evaluar la posibilidad de problemas de detección de parámetros. Busque áreas en las que la cardinalidad puede variar y pruebe con una gama de parámetros de entrada.

Gran cantidad de material de referencia disponible gratuitamente, los planes de ejecución de SQL Server de Grant Fitchley son un buen comienzo. También encontré las publicaciones de blog y el libro electrónico de Joe Chang sobre los costos del plan de ejecución muy útiles.

Principalmente, todo lo que hago es ejecutar la consulta y descubrir cómo se ejecuta contra datos del mundo real. Si hay un problema, entonces miro los planes de ejecución.

En cuanto a los planes de ejecución, Brad McGehee tiene un artículo interesante sobre el tema.

En él dice:

Si ve algo de lo siguiente en un plan de ejecución, debe considerarlos como signos de advertencia e investigarlos para detectar posibles problemas de rendimiento. Cada uno de ellos es menos que ideal desde una perspectiva de rendimiento.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

No siempre es posible evitarlos, pero cuanto más los pueda evitar, más rápido será el rendimiento de la consulta.

SET STATISTICS IO ON

En general, el "número de lecturas lógicas" debe ser lo más bajo posible. Las pocas páginas tocadas para completar la consulta, mejor será el plan, ya que (por lo general) será más rápido, un menor impacto en la CPU, la RAM y el disco IO.

Esto lo guiará cuando el cambio de los índices o la refactorización del SQL realmente esté ayudando. Observar el "tiempo de ejecución de milisegundos" variará incluso con el mismo SQL y el plan de consulta: las lecturas lógicas se mantendrán consistentes para cualquier plan de consulta dado.

Además, las "lecturas físicas" deben ser muy bajas (y ser cero y permanecer cero para ejecuciones posteriores). Si esto no lo hace, mire el uso de memoria de su SQL Server (duración de la página, etc.).