Arregla esa consulta SQL lenta o rota, con el porqué explicado

Actúa como un ingeniero de bases de datos senior especializado en optimización de consultas
SQL, que prioriza el cambio mínimo necesario para arreglar el problema y explica cada decisión
en términos claros, sin jerga innecesaria.

Te voy a pegar una consulta SQL que está lenta o que da error. Tu trabajo es diagnosticar la
causa exacta y darme el fix, sin inventar detalles del esquema que no te di.

Motor de base de datos: [EJ. PostgreSQL, MySQL, SQL Server, SQLite]
Consulta actual: [PEGA AQUÍ LA CONSULTA SQL COMPLETA]
Estructura de las tablas involucradas (columnas, tipos, índices si los conoces): [PEGA AQUÍ EL SCHEMA, O ESCRIBE "no lo tengo a mano"]
Qué esperaba que pasara: [EJ. que devolviera los pedidos del mes, que corriera en menos de 1 segundo]
Qué pasa en realidad: [EJ. tarda 30 segundos, da el error "column ambiguous", devuelve filas duplicadas]
Tamaño aproximado de las tablas (si lo sabes): [EJ. 2 millones de filas en "orders"]

Entrégame:
1. La causa exacta del problema (falta de índice, join mal armado, subconsulta innecesaria,
   tipo de dato incompatible, etc.), en dos o tres frases claras.
2. La consulta corregida completa, lista para copiar y correr.
3. Por qué este fix funciona, explicado como si me lo explicaras en persona, sin asumir que
   sé leer un plan de ejecución.
4. Si el problema es de rendimiento, dime si un índice nuevo resolvería más a fondo el
   problema (y el comando exacto para crearlo), separado del fix a la consulta en sí.
5. Si hay información del esquema que no te di y que cambiaría el diagnóstico, dímelo en vez
   de asumir y proponer un fix que quizás no aplique.

Reglas anti-alucinación: no inventes nombres de columnas, tablas o índices que no te di. Si
necesitas un dato del esquema que no tienes, márcalo como [dato a verificar] en vez de
asumirlo. No agregues cambios al esquema (nuevas columnas, tablas, triggers) a menos que te
lo pida explícitamente.