La tabla temporal podría no ser la mejor opción dependiendo de lo que esté tratando de lograr... Puede ser útil crear una tabla con cierta consolidación de datos para reducir el alcance de las próximas dos solicitudes, pero rara vez es eficiente hacerlo.
Además, no se puede acceder a las tablas temporales varias veces, por lo que se necesitaría una tabla real.
La creación de una tabla requiere escrituras en disco, lo cual es mucho menos eficiente que una selección pura en la RAM. Usando métodos de almacenamiento en caché, puede recuperar el resultado de una selección anterior muy rápido. Puede usar esa selección como la parte DESDE de sus consultas para que sea más rápido que agrupar en una base de datos enorme. Pero incluso entonces...
Estamos evolucionando sobre un conjunto de datos de aproximadamente 1To, las grandes consultas son productos de búsqueda de acuerdo con los derechos de los usuarios (categoría, tienda,...) hemos intentado crear una tabla para cada usuario que indique los productos sobre los que tiene derechos y luego use esa tabla para recuperar los datos sin requerir grandes condiciones, pero aún así fue lento usando SSD. Así que simplemente volcamos una gran cantidad de RAM en el servidor y el SELECT que habríamos usado para llenar las tablas temporales se ejecuta para cada usuario al iniciar sesión, y luego se usa como FROM y todo es perfecto.