¿Cómo se interpreta el plan de explicación de una consulta?

Question

Al intentar comprender cómo se ejecuta una declaración SQL, a veces se recomienda consultar el plan explicativo.¿Cuál es el proceso que uno debe seguir para interpretar (darle sentido) a un plan explicativo?¿Qué debería destacarse como, "Oh, esto está funcionando espléndidamente?" Versus "Oh no, eso no está bien".

Answer 1

Me estremezco cada vez que veo comentarios de que los escaneos de tablas completos son malos y el acceso al índice es bueno.Escaneos completos de tablas, escaneos de rangos de índices, escaneos rápidos de índices completos, bucles anidados, uniones de fusión, uniones hash, etc.Son simplemente mecanismos de acceso que el analista debe comprender y combinar con un conocimiento de la estructura de la base de datos y el propósito de una consulta para llegar a una conclusión significativa.

Un escaneo completo es simplemente la forma más eficiente de leer una gran proporción de los bloques de un segmento de datos (una tabla o una (sub)partición de tabla) y, aunque a menudo puede indicar un problema de rendimiento, eso es sólo en el contexto. de si es un mecanismo eficiente para lograr los objetivos de la consulta.Hablando como alguien de almacén de datos y BI, mi señal de advertencia número uno para el rendimiento es un método de acceso basado en índices y un bucle anidado.

Entonces, para conocer el mecanismo de cómo leer un plan explicativo, la documentación de Oracle es una buena guía: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

Lea también detenidamente la Guía de ajuste de rendimiento.

También tenga un Google para "retroalimentación de cardinalidad", una técnica en la que se puede utilizar un plan explicativo para comparar las estimaciones de cardinalidad en varias etapas de una consulta con las cardinalidades reales experimentadas durante la ejecución.Creo que Wolfgang Breitling es el autor del método.

Entonces, en resumen:comprender los mecanismos de acceso.Comprender la base de datos.Comprender la intención de la consulta.Evite las reglas generales.

Answer 2

Este tema es demasiado grande para responderlo en una pregunta como esta.Deberías tomarte un tiempo para leer. Guía de ajuste del rendimiento de Oracle

Answer 3

Los dos ejemplos siguientes muestran un escaneo COMPLETO y un escaneo RÁPIDO usando un ÍNDICE.

Es mejor concentrarse en su costo y cardinalidad.Al observar los ejemplos, el uso del índice reduce el costo de ejecutar la consulta.

Es un poco más complicado (y no lo manejo al 100%), pero básicamente el costo es una función del costo de CPU y IO, y la cardinalidad es la cantidad de filas que Oracle espera analizar.Reducir ambos es algo bueno.

No olvide que el costo de una consulta puede verse influenciado por su consulta y el modelo del optimizador de Oracle (por ejemplo:COSTE, ELEGIR, etc.) y con qué frecuencia ejecuta sus estadísticas.

Ejemplo 1:

ESCANEAR http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

Ejemplo 2 usando índices:

ÍNDICE http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

Y como ya se sugirió, cuidado con TABLE SCAN.Generalmente puedes evitarlos.

Answer 4

Buscar cosas como escaneos secuenciales puede ser algo útil, pero la realidad está en los números...¡excepto cuando los números son solo estimaciones!lo que suele ser lejos más útil que mirar una consulta plan está mirando lo real ejecución.En Postgres, esta es la diferencia entre EXPLICAR y EXPLICAR ANALIZAR.EXPLAIN ANALYZE en realidad ejecuta la consulta y obtiene información de tiempo real para cada nodo.Eso te permite ver lo que hay de hecho sucediendo, en lugar de lo que el planificador piensa pasará.Muchas veces encontrará que un escaneo secuencial no es un problema en absoluto, sino que es algo más en la consulta.

La otra clave es identificar cuál es el paso realmente costoso.Muchas herramientas gráficas utilizarán flechas de diferentes tamaños para indicar cuánto cuestan las diferentes partes del plan.En ese caso, simplemente busque pasos que tengan flechas delgadas que entran y una flecha gruesa que sale.Si no estás utilizando una GUI, necesitarás observar los números y buscar dónde de repente se vuelven mucho más grandes.Con un poco de práctica resulta bastante fácil identificar las áreas problemáticas.

Answer 5

Realmente para problemas como estos, lo mejor que se puede hacer es PREGUNTA.En particular, su respuesta a esa pregunta contiene enlaces al documento en línea de Oracle, donde se explican muchos de esos tipos de reglas.

Una cosa a tener en cuenta es que los planes explicativos son en realidad las mejores suposiciones.

Sería una buena idea aprender a utilizar sqlplus y experimentar con el comando AUTOTRACE.Con algunos números concretos, generalmente se pueden tomar mejores decisiones.

Pero deberías PREGUNTAR.Él lo sabe todo :)

Answer 6

El resultado de la explicación le indica cuánto tiempo ha tardado cada paso.Lo primero es encontrar los pasos que han tardado mucho y entender lo que significan.Cosas como un escaneo secuencial le indican que necesita mejores índices; es principalmente una cuestión de investigación de su base de datos y experiencia particulares.

Answer 7

Un "Oh, no, eso no está bien" suele adoptar la forma de un escaneo de mesa.Los escaneos de tablas no utilizan ningún índice especial y pueden contribuir a la eliminación de todos los elementos útiles de la memoria caché.En postgreSQL, por ejemplo, verá que se ve así.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

A veces, los escaneos de tablas son ideales en lugar de, por ejemplo, usar un índice para consultar las filas.Sin embargo, este es uno de esos patrones de alerta que parece estar buscando.

Answer 8

Básicamente, usted echa un vistazo a cada operación y ve si las operaciones "tienen sentido" dado su conocimiento de cómo debería funcionar.

Por ejemplo, si está uniendo dos tablas, A y B en sus respectivas columnas C y D (A.C=B.D), y su plan muestra un escaneo de índice agrupado (término de SQL Server, no estoy seguro del término de Oracle) en la tabla A, luego un bucle anidado se une a una serie de búsquedas de índices agrupados en la tabla B, se podría pensar que hay un problema.En ese escenario, es posible que espere que el motor realice un par de escaneos de índice (sobre los índices de las columnas unidas) seguidos de una combinación de fusión.Una investigación más profunda podría revelar malas estadísticas que hagan que el optimizador elija ese patrón de unión o un índice que en realidad no existe.

Answer 9

Mire el porcentaje de tiempo dedicado a cada subsección del plan y considere lo que está haciendo el motor.por ejemplo, si está escaneando una tabla, considere poner un índice en los campos que está escaneando en busca de

Answer 10

Principalmente busco escaneos de índices o tablas.Esto generalmente me indica que me falta un índice en una columna importante que se encuentra en la declaración donde o en la declaración de unión.

De http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx:

Si ve alguno de los siguientes en un plan de ejecución, debe considerarlas señales de advertencia e investigarlas para obtener 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
  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 pueda evitarlos, más rápido rendimiento de la consulta.

Answer 11

Reglas de juego

(probablemente también quieras leer los detalles:

• Documentos de Oracle
• PREGUNTA
• Documentos de SQL Server
  )

Malo

Escaneos de tablas de varias tablas grandes

Bien

Usando un índice único
El índice incluye todos los campos obligatorios.

Victoria más común

En aproximadamente el 90% de los problemas de rendimiento que he visto, la solución más fácil es dividir una consulta con muchas (4 o más) tablas en 2 consultas más pequeñas y una tabla temporal.