¿Cómo interpretas un plan de ejecución de consulta?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Un plan es un árbol de operadores; leerlo significa seguir las filas desde las hojas hacia arriba y comparar lo que el planificador esperaba con lo que ocurrió. EXPLAIN ANALYZE muestra ambas cosas. Lo primero es encontrar la mayor brecha entre filas estimadas y reales, porque una estimación errónea aguas arriba lleva a una estrategia de join errónea aguas abajo. Luego buscar las formas caras: un scan secuencial en una tabla grande donde un filtro es selectivo, un bucle anidado con lado externo grande, un sort o hash que se volcó a disco, y un operador ejecutado miles de veces en un bucle. El arreglo suele ser un índice, estadísticas actualizadas o una reescritura que cambia el orden de joins, y el plan se vuelve a leer tras cada cambio.

Ejemplo

Una consulta de informe tardaba 40 segundos; el plan mostraba un hash join cuyo lado interno se estimaba en 200 filas pero producía 2 millones porque las estadísticas de una tabla recién cargada estaban obsoletas. Ejecutar ANALYZE corrigió la estimación, el planificador pasó a un merge join con índice y la consulta bajó a 900 ms. Una segunda mirada encontró un sort volcado a disco que un índice cubriente eliminó.

Errores frecuentes

• Leer solo el número de coste total e ignorar las estimaciones de filas.
• Añadir un índice para el operador con mayor coste cuando el problema real es una mala estimación aguas arriba.
• Ajustar con EXPLAIN sin ANALYZE y no ver nunca las filas reales.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.