it-swarm-es.tech

¿Cómo interpretas el plan explicativo de una consulta?

Cuando se intenta comprender cómo se está ejecutando una instrucción SQL, a veces se recomienda consultar el plan de explicación. ¿Cuál es el proceso por el que se debe pasar al interpretar (tener sentido) un plan de explicación? ¿Qué debería destacar como "Oh, esto está funcionando espléndidamente?" versus "Oh no, eso no está bien".

87
user290

Me estremezco cada vez que veo comentarios de que las tablas de todas las celdas son malas y el acceso al índice es bueno Las exploraciones de tabla completa, las exploraciones de rango de índice, las exploraciones de índice completo rápidas, los bucles anidados, la combinación de combinación, las combinaciones hash, etc. son simplemente mecanismos de acceso que debe ser entendido por el analista y combinados con un conocimiento de la estructura de la base de datos y el propósito de una consulta en Para llegar a cualquier conclusión significativa.

Una exploración completa es simplemente la forma más eficiente de leer una gran parte de los bloques de un segmento de datos (una tabla o una (sub) partición de la tabla) y, aunque a menudo puede indicar un problema de rendimiento, eso es solo en el contexto de si es un mecanismo eficiente para lograr los objetivos de la consulta. Hablando como almacén de datos y tipo de BI, mi indicador de advertencia número uno para el rendimiento es un método de acceso basado en índices y un bucle anidado.

Entonces, para 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

Tenga una buena lectura a través de la Guía de ajuste de rendimiento también.

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

Entonces, en definitiva: entender los mecanismos de acceso. Comprender la base de datos. Comprender la intención de la consulta. Evite las reglas de oro.

78
David Aldridge

Este tema es demasiado grande para responder en una pregunta como esta. Debería tomarse un tiempo para leer Guía de ajuste de rendimiento de Oracle

13
Tony Andrews

Los dos ejemplos a continuación muestran un escaneo COMPLETO y un escaneo RÁPIDO utilizando un ÍNDICE.

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

Es un poco más complicado (y no tengo un 100% de control), pero básicamente el Costo es una función de la CPU y IO costo, y la Cardinalidad es el número de filas que Oracle espera analizar . Reducir ambos es algo bueno.

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

Ejemplo 1:

SCAN 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ó, ten cuidado con TABLE SCAN. Generalmente se pueden evitar estos.

5
Mark Nold

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 normalmente es lejos más útil que mirar una consulta plan es mirar la ejecución real. En Postgres, esta es la diferencia entre EXPLAIN y EXPLAIN ANALYZE. EXPLAIN ANALYZE en realidad ejecuta la consulta y obtiene información de tiempo real para cada nodo. Eso le permite ver lo que está pasando en realidad, en lugar de lo que sucederá con el planificador piensa. 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 usarán flechas de diferentes tamaños para indicar cuánto cuestan las diferentes partes del plan. En ese caso, solo busque los pasos que tienen flechas finas y una flecha gruesa que se va. Si no está utilizando una GUI, deberá observar los números y buscar dónde se vuelven mucho más grandes. Con un poco de práctica, es bastante fácil distinguir las áreas problemáticas.

4
decibel

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

Una cosa a tener en cuenta, es que explicar los planes son realmente las mejores conjeturas.

Sería una buena idea aprender a usar sqlplus y experimentar con el comando AUTOTRACE. Con algunos números difíciles, generalmente puedes tomar mejores decisiones.

Pero deberías preguntarle. Él lo sabe todo al respecto :)

3
EvilTeach

La salida de la explicación le indica cuánto tiempo ha tomado cada paso. Lo primero es encontrar los pasos que han tomado mucho tiempo y comprender lo que significan. Cosas como un escaneo secuencial le dicen que necesita mejores índices; se trata principalmente de una investigación de su base de datos y experiencia particulares.

2
Tom Leys

Un "Oh no, eso no es correcto" a menudo tiene la forma de exploración de tabla. Las exploraciones de tablas no utilizan ningún índice especial y pueden contribuir a la purga de todos los útiles en los cachés de memoria. En postgreSQL, por ejemplo, encontrará que se ve así.

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

A veces, las exploraciones de tablas son ideales si se utiliza un índice para consultar las filas. Sin embargo, este es uno de esos patrones de bandera roja que parece estar buscando.

2
convex hull

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

Por ejemplo, si está uniendo dos tablas, A y B en sus respectivas columnas C y D (AC = BD), y su plan muestra una exploración de índice agrupado (término de SQL Server - no está seguro del término de Oracle) en la tabla A, luego una unión de bucle anidado a una serie de búsquedas de índices agrupados en la tabla B, podría pensar que hubo un problema. En ese escenario, puede esperar que el motor realice un par de exploraciones de índice (sobre los índices en las columnas unidas) seguidas de una combinación de combinación. Una investigación adicional podría revelar estadísticas erróneas que hacen que el optimizador elija ese patrón de unión, o un índice que en realidad no existe.

2
Jonathan Rupp

observe el porcentaje de tiempo empleado en cada subsección del plan y considere qué está haciendo el motor. por ejemplo, si está escaneando una tabla, considere colocar un índice en el campo (s) que está escaneando

1
Steven A. Lowe

Principalmente busco el índice o la tabla de escaneos. Esto generalmente me dice que me estoy perdiendo un índice en una columna importante que está en la declaración where o la instrucción join.

Desde 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 considerarlos 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
  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 será el rendimiento de las consultas.

1
dpollock