Al intentar comprender cómo se está ejecutando una declaración SQL, a veces se recomienda mirar el plan de explicación. ¿Cuál es el proceso por el que se debe pasar para interpretar (dar sentido) a un plan de explicación? ¿Qué debería destacarse como "Oh, esto está funcionando espléndidamente"? versus "Oh no, eso no está bien".
Respuestas:
Me estremezco cada vez que veo comentarios de que los exámenes de tabla completos son malos y el acceso al índice es bueno. Los escaneos completos de tablas, escaneos de rango de índice, escaneos rápidos de índice completo, bucles anidados, combinación de combinación, combinaciones de 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, si bien 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 un almacén de datos y un tipo de BI, mi bandera 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 de explicación, 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
También lea atentamente 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 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 resumen: comprenda los mecanismos de acceso. Comprende la base de datos. Comprende la intención de la consulta. Evite las reglas generales.
Este tema es demasiado grande para responder con una pregunta como esta. Debería tomarse un tiempo para leer la Guía de ajuste de rendimiento de Oracle
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 tengo un control del 100%) pero básicamente el costo es una función del costo de la CPU y del 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 optimizador de Oracle (por ejemplo: COST, CHOOSE, etc.) y la frecuencia con la que ejecuta sus estadísticas.
Ejemplo 1:
ESCANEAR http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
Ejemplo 2 usando índices:
INDEX http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
Y como ya se sugirió, tenga cuidado con TABLE SCAN. Por lo general, puede evitarlos.
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 mucho más útil que mirar un plan de consulta es observar la ejecución real . En Postgres, esta es la diferencia entre EXPLAIN y EXPLAIN ANALYZE. EXPLAIN ANALYZE realmente ejecuta la consulta y obtiene información de tiempo real para cada nodo. Eso le permite ver lo que realmente está sucediendo, en lugar de lo que el planificador cree que sucederá. 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 pasos que tengan flechas delgadas entrando y saliendo una flecha gruesa. Si no está utilizando una GUI, tendrá que mirar 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.
Realmente para problemas como estos, lo mejor que se puede hacer es ASKTOM . En particular, su respuesta a esa pregunta contiene enlaces al documento de Oracle en línea, donde se explican muchos de esos tipos 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 concretos, generalmente puede tomar mejores decisiones.
Pero deberías PREGUNTAR. Él lo sabe todo :)
El resultado de la explicación le dice cuánto tiempo ha tomado cada paso. Lo primero es encontrar los pasos que lleva mucho tiempo y comprender lo que significan. Cosas como un escaneo secuencial le dicen que necesita mejores índices; es principalmente una cuestión de investigación en su base de datos y experiencia particulares.
Un "Oh no, eso no es correcto" a menudo tiene la forma de un escaneo de tabla . Los escaneos de tablas no utilizan índices especiales y pueden contribuir a purgar todos los elementos útiles de las memorias caché. En postgreSQL, por ejemplo, encontrará que tiene este aspecto.
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)
A veces, los escaneos de tablas son ideales, por ejemplo, utilizando un índice para consultar las filas. Sin embargo, este es uno de esos patrones de bandera roja que parece estar buscando.
Básicamente, echas un vistazo a cada operación y ves si las operaciones "tienen sentido" dado tu conocimiento de cómo debería funcionar.
Por ejemplo, si está uniendo dos tablas, A y B en sus respectivas columnas C y D (AC = BD), 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 que se une a una serie de búsquedas de índices agrupados en la tabla B, podría pensar que hay un problema. En ese escenario, puede esperar que el motor realice un par de escaneos de índice (sobre los índices de las columnas unidas) seguidos de una combinación de combinación. Una investigación más profunda podría revelar estadísticas incorrectas que hagan que el optimizador elija ese patrón de combinación o un índice que en realidad no existe.
observe 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
Principalmente busco escaneos de índices o tablas. Esto generalmente me dice que me falta un índice en una columna importante que está en la instrucción where o en la instrucción join.
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 considerarlos como señales de advertencia e investigarlos para detectar posibles problemas de rendimiento. Cada uno de ellos es menos que ideal desde una perspectiva de desempeño.
* 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 los pueda evitar, más rápido será el rendimiento de las consultas.
(probablemente también quieras leer los detalles:
Escaneos de tablas de varias tablas grandes
El uso de un índice único El índice
incluye todos los campos obligatorios
En aproximadamente el 90% de los problemas de rendimiento que he visto, la victoria 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.