Query super lento

[gnzsoloyo]

Mi estimado: Antes de opinar sobre la validez o no de los JOIN, o incluso hablar de performance, deberías trabajar mucho más en BBDD, en especial en aplicaciones "vivas", es decir aquellas que no consuman recursos de DataWarehouses o DataMarts, y que son en definitiva las que alimentan a esos DW y DM.
Las bases de da,tos operativas n¿NO usan tablas de resumen, porque son tablas calientes, tablas que se están poblando y modificando todo el tiempo, y son los recursos de consolidación de datos los que generan esos resúmenes que tanto adoras.
Pero por detrás, y ANTES de que algo pueda resumirse, hay SQL muy poderoso que usa pura y exclusivamente operaciones de JOIN explicito e implícito, porque si ellos NO ES POSIBLE hacer luego los resúmenes de los DW.
Una base de datos normalizada no sirve si no usas JOINs. Si quieres hablar de otro tipo de BBDD, por ejemplo NoSQL, entonces no estamos hablando del mismo paradigma, por lo que la discusión derivará en la nada.
Ahora bien, para los programadores en general, no existen los JOIN porque simplemente muchos de ellos no los entienden, dado que para comprenderlos y dominarlos se requiere razonar de un modo distinto. tu planteas PROCESOS, y en el SQL no existe SQL basado en procesos, sino procesos que se hacen CON SQL. Un proceso iterativo para construir resúmenes es ineficiente en tablas normalizadas, porque entre otras cosas requiere el consumo de cantidades ingentes de recursos de sistema que son innecesarios, un desperdicio de tiempo de procesos, memoria, cambios de contexto excesivos, y un enorme etcétera. ¿Por qué voy a usar lecturas simples para luego resumir, si puedo resumir al mismo tiempo que hago la consulta... y además de forma más rápida?
¿Por ventura, crees que todos los sistemas bancarios usan SQL con JOIN por capricho? ¿O los sistemas de venta on-line? ¿Crees que no los usan?

Dejando el tema alli, puesto que dudo que lo que pueda decirte para mostrarte otra perspectiva que la que ya tienes instalada en tu sistema lógico haga que reveas tus afirmaciones, volvamos al problema del hilo.

En principio, sin ver la estructura delas tablas, hay cosas que no queda claras en cuanto a donde se originan, pero el punto central es que para hacer optimización hay que al menos reducir la cantidad de registros que lee en la primera tabla. Esa es la que podría ser que tenga baja selectividad y esté devolviendo demasiados registros (más de 150.000). Hay que analizar si es posible agregarle algun valor al WHERE, un índice adicional, o bien cambiar el orden de lectura.
Si el resumen apunta a determinados clientes, hay que basarlo en la tabla relacionada con ellos, que siempre será menor que sus movimientos, por ejemplo. Yo comenzaría por ese lado.
Además hay que verificar que no haya conversiones implícitas (no tratar números como cadenas de texto), y si es posible reemplazar los valores de cadena del WHERE por sus identificadores numéricos (si existen), también ayuda.