Hola Alicia:
El desempeño de una consulta en cualquier manejador de Base de Datos depende no sólo de la consulta en si, sino de muchos factores que la pueden afectar, sin embargo, en tu post das muy poca (o nada) de información al respecto:
Primero, no nos dices con qué Base de Datos estás trabajando, por lo tanto es un tanto complicado darte una respuesta puntual en cuanto a cómo puedes cambiar la consulta, pues la sintaxis entre cada DBMS puede variar bastante. Además tendríamos que revisar también la configuración del propio servidor, para ver si hay algo que pueda afectar la velocidad de ejecución.
Segundo, no nos dices cuál es la estructura de cada una de tus tablas, ni pones datos de ejemplo por lo tanto, no sabemos qué índices tiene cada una de ellas ni de qué tipos son tus campos. El desempeño en las consulta suele estar directamente relacionado con los índices y los tipos de dato, por ejemplo en la búsquedas tipo IN sobre cadenas.
Tercero, no nos das información acerca del volumen de información que hay en tus tablas. Este también puede ser un factor que influye en el desempeño de las consultas. Si hablamos de millones de registros debes de usar estrategias distintas a si hablamos de unos cuantos cientos o miles.
Cuarto, no nos dices cómo están relacionadas las tablas (1 a 1, 1 a muchos, muchos a muchos) por lo tanto tampoco podemos decirte alguna otra alternativa a las subconsultas que estas haciendo, ya que el uso excesivo de sobconsultas es un factor que debes de evitar en lo posible.
Entonces, sin toda esta información, cualquier respuesta que te podamos dar sería tratar de jugar al adivino y no podríamos asegurar que funcione. Pero bueno, tratemos de jugar al Nostradamus y veamos si esto te puede servir.
Como dije en el punto cuatro, no es recomendable hacer tantas sobconsultas en el SELECT, es mejor hacer tantos JOIN's como necesites. Suponiendo que todas tus tablas se relaciones 1 a 1 entonces podrías hacer algo así:
No estoy seguro de que esto pueda funcionar o que te dé el mismo resultado que esperas... como dije, estoy simplemente de tratar de adivinar sin más información. Además, aquí hay algunas mejores prácticas que te pueden ayudar.
1. Hay algunos campos en donde no loes antepones el nombre de la tabla a la que pertenecen:
Es recomendable que TODOS LOS CAMPOS TENGAN EL PREFIJO DE LA TABLA A LA QUE PERTENECEN, ya que de lo contrario el DBMS tiene que hacer una comprobación lógica sobre de todas las tablas para saber qué campo debe pintar y además suelen pasar errores de columna ambigua.
2. La cláusula IN es una de las que peor desempeño tienen en base de datos, sobre todo cuando comparas contra cadenas. Puedes probar cambiarla por comparaciones tipo AND-OR:
3. Por definición, la ordenación es un proceso muy lento, sobre todo si no tienes un uso adecuado de índices. Prueba ejecutar la consulta SIN ORDER BY y compara los tiempos de respuesta. Como te dije en los puntos segundo y tercero, sin saber qué indices tienes y qué cantidad de registros tienen tus tablas, es imposible saber si hay algo que se pueda mejorar.
Finalmente, la mayoría de los DBMS's actuales tienen herramientas para analizar tus consultas, como el plan de ejecución de SQL Server o el EXPLAIN de MySQL... investiga si tu Motor de Base de Datos tiene alguna de estas utilerías para optimizar tus consultas.
Has la prueba y nos comentas, y si continuas con problemas, entonces atiende a lo que te comento y danos más información de tu modelo.
Saludos
Leo.