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?

sql-server performance query

Respuestas:

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.

— Mark Storey-Smith
fuente

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.

— Ricardo
fuente

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.).

— Chico
fuente

Pero para las consultas que se ejecutan cuando no hay en el caché de consultas, las lecturas físicas serán mayores que cero, ¿verdad? Quiero decir, no siempre puedes evitar eso, ya que no todas las consultas (especialmente las consultas ad hoc) se almacenan en caché. ¿Estoy en lo correcto?

— Thomas Stringer

@ Surfer513 para encargarse del almacenamiento en caché de datos, puede emitir un PUNTO DE COMPROBACIÓN seguido de DROPCLEANBUFFERS de DBCC para borrar el grupo de búferes (caché de datos). Tenga en cuenta que esto eliminará las memorias intermedias para todos, así que úselo en consecuencia (en sistemas de prueba).

— StanleyJohns

@StanleyJohns, ¿por qué querrías borrar el caché de datos / consultas?

— Thomas Stringer

De esta forma, el IO físico será el mismo cada vez, dando la consistencia requerida para las pruebas. Esto ayudará a ajustar la consulta.

— StanleyJohns

Ignoraría las estadísticas físicas de E / S, ya que está bajo el control de la infraestructura subyacente e incorporará el almacenamiento en búfer SAN y OS. Las E / S lógicas son una medida de la cantidad de TRABAJO que tuvo que hacer la instrucción SQL. Si el SQL hace menos IO lógico, entonces hace menos trabajo.

— Chico