Estou reiterando a pergunta feita por Mongus PongPor que usar uma tabela temporária seria mais rápido que uma consulta aninhada? que não tem uma resposta que funcione para mim.

A maioria de nós em algum momento acha que quando uma consulta aninhada atinge uma certa complexidade, ela precisa ser dividida em tabelas temporárias para mantê-la performativa. Isto éabsurdo que isso poderia ser o caminho mais prático e significa que esses processos não podem mais ser vistos. E muitas vezes aplicativos de BI de terceiros só funcionam bem com visualizações, por isso isso é crucial.

Estou convencido de que deve haver uma configuração simples de plano de consulta para fazer com que o mecanismo apenas gere cada subconsulta, trabalhando de dentro para fora. Não há como adivinhar como isso pode tornar a subconsulta mais seletiva (o que às vezes acontece com muito sucesso) e nenhuma possibilidade de subconsultas correlacionadas. Apenas a pilha de dados que o programador pretendia retornar pelo código independente entre os colchetes.

É comum para mim descobrir que simplesmente mudar de uma subconsulta para uma # tabela leva o tempo de 120 segundos para 5. Essencialmente, o otimizador está cometendo um grande erro em algum lugar. Claro, pode haver maneiras muito demoradas de convencer o otimizador a ver as tabelas na ordem correta, mas mesmo isso não oferece garantias. Eu não estou pedindo o tempo de execução ideal de 2 segundos aqui, apenas a velocidade que o temp tabling me oferece dentro da flexibilidade de umVisão.

Eu nunca postei aqui antes, mas tenho escrito SQL há anos e li os comentários de outras pessoas experientes que acabaram de aceitar esse problema e agora eu gostaria apenas que o gênio apropriado desse um passo adiante e diga dica especial é X ...