Reitero la pregunta formulada por Mongus Pong.¿Por qué utilizar una tabla temporal sería más rápido que una consulta anidada? Lo que no tiene una respuesta que funcione para mí.

La mayoría de nosotros, en algún momento, descubrimos que cuando una consulta anidada alcanza una cierta complejidad, debe dividirse en tablas temporales para mantener su rendimiento. Esabsurdo que esta podría ser la manera más práctica de avanzar y significa que estos procesos ya no pueden convertirse en una vista. Y, a menudo, las aplicaciones de BI de terceros solo se reproducen bien con vistas, por lo que esto es crucial.

Estoy convencido de que debe haber una configuración simple de queryplan para que el motor simplemente enrute cada subconsulta a su vez, trabajando desde adentro hacia afuera. No hay que adivinar cómo puede hacer que la subconsulta sea más selectiva (lo que a veces hace con mucho éxito) y no hay posibilidad de subconsultas correlacionadas. Solo la pila de datos que el programador pretendía devolver por el código autocontenido entre los corchetes.

Es común para mí encontrar que simplemente cambiar de una subconsulta a una #table lleva el tiempo de 120 segundos a 5. Esencialmente, el optimizador está cometiendo un gran error en algún lugar. Claro, puede haber muchas maneras de consumir mucho tiempo para convencer al optimizador de que mire las tablas en el orden correcto, pero incluso esto no ofrece ninguna garantía. No estoy pidiendo el tiempo de ejecución ideal de 2 segundos aquí, solo la velocidad que me ofrece la tabla temporal dentro de la flexibilidad de unver.

Nunca he publicado aquí antes, pero he estado escribiendo SQL durante años y he leído los comentarios de otras personas experimentadas que también acaban de aceptar este problema y ahora me gustaría que el genio apropiado diera un paso adelante y dijera sugerencia especial es X ...