Lanzas la funcionalidad, funciona en tu portátil, y luego un endpoint tarda tres segundos en producción. Ya sabes que la culpable es una consulta. Lo que no sabes es qué parte, y la herramienta que se supone que te lo dice te devuelve un muro de texto indentado con números que tienes que mirar con lupa.
Ese muro de texto es un plan EXPLAIN, y contiene toda la respuesta. La base de datos te está diciendo exactamente cómo va a ejecutar tu consulta, nodo a nodo, con un coste en cada uno. El problema es el formato. Un plan en bruto es denso, está muy anidado y está optimizado para un parser, no para una persona que lo lee un viernes a las 4 de la tarde. Así que la mayoría buscamos la palabra "Seq Scan", sentimos un vago temor y pasamos a otra cosa.
El plan es un árbol que se hace pasar por texto
Todo plan EXPLAIN es en realidad un árbol. La raíz es el resultado final, sus hijos son los pasos que lo alimentan, y cada paso lleva un coste estimado. Cuando lo vuelcas como texto, esa estructura se aplana en indentación, y lo único que de verdad te importa (dónde se va el tiempo) queda enterrado entre filas, anchos y recuentos de bucles.
La solución es dejar de leer el árbol como texto y empezar a verlo como un árbol. Pide primero el formato pensado para máquinas:
-- Postgres: ask for JSON so the plan keeps its structure EXPLAIN (ANALYZE, FORMAT JSON) SELECT u.name, count(o.id) FROM users u JOIN orders o ON o.user_id = u.id WHERE o.created_at > '2026-01-01' GROUP BY u.name;
Postgres (y MySQL, con su propio FORMAT=JSON) responderá con un documento JSON en lugar del texto habitual. Se ve así, y sinceramente no es mucho más fácil de leer a mano:
[{ "Plan": {
"Node Type": "Hash Join",
"Total Cost": 18422.6,
"Plans": [
{ "Node Type": "Seq Scan",
"Relation Name": "orders",
"Total Cost": 15903.0 },
{ "Node Type": "Index Scan",
"Relation Name": "users",
"Total Cost": 211.4 }
] } }]
Pega el EXPLAIN de PostgreSQL o MySQL y la parte lenta se ilumina
Copia ese JSON, abre el diálogo Generar desde código de LetDraw y pégalo. No tienes que decirle qué está viendo. LetDraw detecta automáticamente un plan EXPLAIN de Postgres o MySQL y lo representa como un árbol del plan con mapa de calor: el árbol real, dibujado, con cada nodo coloreado según su coste.
El nodo más caro es el más rojo. Esa es toda la revisión, de un solo vistazo.
Los nodos calientes brillan en rojo y naranja; los baratos se quedan en verde. Así, en lugar de analizar costes a ojo, miras el dibujo y tu atención va directa al cuello de botella.
orders hace casi todo el trabajo; el lado de users ya está indexado.Ahora el diagnóstico es evidente. El lado de orders es un Seq Scan, una lectura completa de la tabla, mientras que users ya se sirve con un Index Scan. El hash join de arriba es caro porque lo alimenta ese recorrido completo. El índice que falta en orders(created_at) no es algo que hayas deducido de una columna de costes; es la única caja roja de la página.
Tu consulta nunca sale del navegador
Esta es la parte por la que la gente de bases de datos suele preguntar primero. Un plan EXPLAIN puede revelar nombres de tablas, nombres de columnas y estimaciones de filas que preferirías no entregar a una herramienta web cualquiera. LetDraw lo ejecuta todo en el cliente. El análisis y la maquetación ocurren en tu navegador, en tu máquina. Nada de tu consulta ni de tu esquema se sube a un servidor para generar el dibujo.
- Pega un plan de una base de datos de producción sin que salga de tu portátil
- No hace falta cuenta ni subir nada para convertir un plan en árbol
- La misma privacidad se aplica tanto si usas la app alojada como si la autoalojas
EXPLAIN (ANALYZE) cuando puedas permitirte ejecutar realmente la consulta. Los costes pasan a ser tiempos medidos en lugar de estimaciones, y el mapa de calor refleja dónde se fue el tiempo de verdad, no solo dónde el planificador supuso que se iría.Es un diagrama, así que puedes actuar sobre él
El árbol del plan no es una imagen estática. Está hecho de las mismas formas editables que todo lo demás en LetDraw, lo que significa que, en cuanto detectas el problema, puedes convertirlo en algo que un compañero entienda.
- Rodea la ruta caliente con un círculo y añade una nota que explique el índice que falta
- Pega los planes de antes y después uno al lado del otro para mostrar que la corrección funcionó
- Exporta a PNG, SVG o PDF y adjúntalo al pull request o al informe del incidente
Un plan en bruto es algo que un ingeniero descifra a solas. Un árbol con mapa de calor y una nota sobre la caja roja es algo que toda la revisión entiende en pocos segundos. Esa es la diferencia entre "la consulta es lenta" y "esta es la parte lenta, y esta es la corrección de una línea". Pega tu próximo plan EXPLAIN y deja que el cuello de botella se presente solo.