Introducción
La consulta SQL describe el resultado esperado, no la forma de obtener el resultado. El conjunto de pasos específicos que debe seguir el servidor para devolver el resultado se denomina plan de ejecución de la consulta. El plan es construido por el optimizador. La selección de un plan afecta la velocidad de ejecución, lo que lo convierte en uno de los elementos más importantes del análisis de problemas de rendimiento de consultas.
El plan de ejecución comprende operadores y sus propiedades que están interrelacionadas entre sí en forma de estructura de árbol. Cada operador es responsable de una operación lógica o física separada. En conjunto, aseguran el resultado descrito en el texto de la consulta. Dentro del árbol, los operadores están representados por los objetos de clase en la memoria de SQL Server. Los usuarios del servidor (es decir, usted y yo) ven la descripción generada en formato XML con un esquema específico, que se muestra gráficamente en el entorno de SQL Server Management Studio (SSMS).
Hay muchos operadores de planes diferentes e incluso más propiedades. Además, de vez en cuando surgen nuevos. Este artículo no se atreve a describir toda la variedad posible de operadores. En cambio, me gustaría compartir las adiciones más interesantes en este tema y recordar algunos elementos antiguos pero útiles.
Versión del servidor
A veces puede encontrar solicitudes para la versión del servidor en los foros, incluso si el plan de consulta se proporciona en el formato correcto (XML). En su lugar, puede ahorrar tiempo y abrir el plan de ejecución como XML. Y el primer elemento que describe el plan le mostrará la versión del servidor en la propiedad Build.
Este método no permite recuperar la información completa sobre la edición del servidor, pero en la mayoría de los casos es suficiente para comprender de qué tratamos.
Número de filas de la tabla
La segunda pregunta frecuente es "¿Cuántas filas contiene su tabla?". Esta información también se puede recuperar del plan de consulta (a partir de la versión del servidor 2008). Para ello, debemos seleccionar el operador de acceso a datos (Scan o Seek) de una tabla en cuestión y echar un vistazo a la TableCardinality propiedad. Hay una propiedad más interesante, Tamaño de fila estimado, para la especificación del tamaño de la fila y la evaluación aproximada del tamaño de la tabla o índice (dado que la tabla no está comprimida).
Me gustaría señalar que este no es un número real de filas en una tabla, sino datos de las estadísticas de objetos. Sin embargo, estos datos son la base de las decisiones que toma el optimizador al crear una consulta.
Contexto
El plan de consulta guarda configuraciones SET notables para las que fue creado. Para ver la configuración, debe seleccionar un elemento raíz en el plan y expandir Establecer opciones propiedad. Por ejemplo, podemos saber si el plan se construyó con el ARITHABORT opción habilitada (la diferencia de esta configuración a menudo conduce a dos planes y situaciones diferentes con un análisis de parámetros incorrecto).
Número de CPU
Podemos recuperar la cantidad de procesadores que están disponibles para el optimizador. Para esto, necesitamos abrir la OptimizerHardwareDependentPropertie s -> Grado de paralelismo disponible estimado parámetro en el mismo elemento raíz y multiplíquelo por 2. Si solo hay un procesador disponible, no hay necesidad de multiplicar.
2*2 =4, 4 CPU están disponibles. De hecho, tengo un procesador de 4 núcleos en mi computadora y los 4 núcleos están disponibles para el servidor. Esta información puede ayudarlo a detectar la máquina en la que se generó el plan.
Versión del estimador de cardinalidad
A partir de SQL Server 2014, varias versiones de Cardinality Estimator (RU) están disponibles. Este mecanismo afecta a la mayoría de las decisiones que toma el optimizador al seleccionar un plan. Puede recuperar la versión de Cardinality Estimator de CardinalityEstimationModelVersion propiedad del operador raíz.
- 0:servidor SQL <=2012
- 120:Servidor SQL 2014
- 130:Servidor SQL 2016
- 140 – SQL Server vSiguiente
Tiempo de ejecución de consultas y tiempo de espera
A partir de SQL Server 2016 SP1, el plan de consulta real presenta información sobre el tiempo de ejecución y el tiempo del procesador. Para recuperar estos datos, debe expandir QueryTimeStats propiedad en el elemento raíz y ver los valores de CpuTime y Tiempo transcurrido . No necesitamos habilitar la recopilación del tiempo de ejecución o preguntar "¿cuánto tiempo se ejecutó la consulta?" nunca más:toda esta información está incluida en el plan.
La segunda mejora notable es el top 10 de las esperas más largas durante la ejecución de consultas. Para esto, necesitamos expandir el WaitStats propiedad en el elemento raíz. Esta adición permite obtener razones más exactas de la ejecución lenta de consultas y simplifica significativamente los diagnósticos.
Tipos de parámetros
La Lista de parámetros La propiedad, que enumera los parámetros utilizados en la consulta, existía en el plan hace mucho tiempo. Sin embargo, a partir de SQL Server 2016 SP1, el Tipo de datos de parámetro La propiedad se ha agregado a la definición del parámetro. Esta propiedad almacena el tipo de datos del parámetro. Puede ser útil para comprender problemas con la conversión de tipos.
Número de filas leídas y número estimado de filas que se leerán
El plan de ejecución incluye dos propiedades muy importantes, Número real de filas y Número estimado de filas. Estas propiedades contienen información sobre el número de filas devueltas por el operador de lectura de datos, pero no el número de filas que realmente ha leído. Las propiedades Número de filas leídas y Número estimado de filas para leer responden a esta pregunta y permiten recuperar el número de filas que el servidor ha leído o va a leer. La propiedad ActualRowsRead (Número de filas leídas en SSMS) está disponible a partir de SQL Server 2012 SP3, 2014 SP2, 2016 SP1. EstimatedRowsRead (Número estimado de filas para leer en SSMS) la propiedad está disponible a partir de SQL Server 2016 SP1.
Estadísticas de IO y tiempo de ejecución del operador
Hay varias propiedades muy útiles establecidas en SQL Server 2016, 2014 SP2 y disponibles en el plan de consulta real. Son métricas de IO (si un operador tiene IO) – Estadísticas de IO reales, CPU y métricas de tiempo de ejecución – Estadísticas de tiempo real y métricas de memoria (a partir de 2016 SP1, si un operador requiere memoria).
Las propiedades incluyen las siguientes métricas nuevas que se pueden dividir en subprocesos en el caso del plan paralelo:
- ActualElapsedms
- CPU reales
- Exploración actual
- Lecturas lógicas reales
- Lecturas físicas reales
- Lectura anticipada real
- ActualLobLogicalReads
- Lecturas físicas reales de Lob
- RealLobLecturaAdelante
- Concesión de memoria de entrada
- Concesión de memoria de salida
- Concesión de memoria usada
Como puede ver en la lista anterior, puede recuperar información completa sobre la ejecución de cualquier operador, E/S consumida y memoria. En las últimas versiones de SSMS, estas métricas se representan en la ventana de propiedades. Si usa una versión anterior de SSMS, puede recuperarlos abriendo el plan como XML. En mi opinión, ahora hay todo para mostrar porcentajes no por costo estimado, sino por recursos reales transcurridos (creé una sugerencia en Connect. Entonces, si le gusta la idea, vote por ella).
Información sobre indicadores de rastreo habilitados
Los indicadores de seguimiento en SQL Server son "cambios" especiales del comportamiento predeterminado del servidor a un comportamiento diferente. A partir de SQL Server 2014 SP2 y 2016 SP1, la información sobre las marcas de rastreo habilitadas está disponible en la propiedad TraceFlags del elemento específico. Puede incluir hasta 100 banderas habilitadas simultáneamente en el momento de la construcción de la consulta.
Información sobre el derrame de datos en tempdb
Algunos operadores de plan, por ejemplo, como Sort o Hash Match, requieren memoria durante la ejecución de la consulta. Sin embargo, el volumen de memoria se calcula en el momento de la compilación. Debido a varias razones (por ejemplo, evaluación incorrecta del número o filas supuestas), el volumen de la memoria puede calcularse incorrectamente. Si se asigna menos memoria de la que se requiere para la ejecución, el servidor tendrá que volcar datos a tempdb. Ralentiza la ejecución de consultas. La precaución sobre tal situación se introdujo en el servidor 2012, pero a partir de SQL Server 2012 SP3, 2014 SP2, 2016, la información de diagnóstico se ha ampliado y ahora incluye el volumen de datos derramados y datos leídos. Así, puedes evaluar el problema y tomar las medidas adecuadas.
Conclusión
El plan de ejecución incluye mucha información útil, el plan de consulta real incluye aún más información y el plan de consulta real en las últimas versiones de SQL Server es solo una mina de información útil. Este artículo no pretende enseñar a alguien a analizar planes de consulta. En cambio, consideré las propiedades del plan más interesantes, incluidas las propiedades nuevas y las antiguas, pero subestimadas. Espero que este artículo lo ayude la próxima vez que necesite analizar el rendimiento de las consultas.
El artículo fue traducido por el equipo de Codingsight con el permiso del autor.
Herramienta útil:
dbForge Query Builder para SQL Server:permite a los usuarios crear consultas SQL complejas rápida y fácilmente a través de una interfaz visual intuitiva sin necesidad de escribir código manualmente.
