Considere 5 tabelas com mais de 1 bilhão de registros cada.
Uma consulta precisa juntá-los. E eu sei que menos de 10% de seus registros serão exigidos. Digamos que todos tenham uma dimensão de data e que apenas os dados do mês atual sejam necessários.
O que deve ser mais rápido:
1) Use um simples SELECT: junte todas as tabelas e filtre (WHERE) a dimensão de cada tabela para o mês atual.
2) crie 5 tabelas temporárias, filtrando cada tabela de origem pelos registros do mês atual, aqui também podemos aproveitar para selecionar apenas as colunas obrigatórias, depois juntar essas tabelas temporárias.
Possibilidade extra:
3) Manter tabelas secundárias, tendo apenas os dados do mês/ano atual. Essas tabelas são mantidas pelo mesmo ETL que alimenta as principais.
Construa a consulta e veja.
O otimizador de consulta geralmente é inteligente o suficiente para filtrar antecipadamente.
SQL é lógico - no onde não significa que será processado por último.
Claramente você quer índices em join e filter.
Quando você chega a 5 ou mais junções, o otimizador geralmente fica na defensiva e entra em uma junção de loop.
Eu tenho uma citação - não. É uma observação.
Quando chegar a 5 ou mais, puxar as condições para a junção pode ajudar o otimizador.
Eu tenho uma citação - não. É uma observação.
Construa uma junção de cada vez e veja quando fica estúpido.
Otimize uma junção de cada vez.
Se você vai se materializar, coloque um pk no #temp.
Comece com onde você acha que vai obter o maior estrondo.
A condição OR em que /join são os maiores problemas e geralmente levam a uma junção de loop.
Esses devem ser os primeiros a se materializar.
Você pode forçar a junção de hash, mas isso é uma ladeira escorregadia que pode dar errado.
Parece meio estranho todas as tabelas terem uma dimensão de data, você normalmente teria algumas tabelas de tipo de pesquisa com dados de tipo mais estático.
Se você não precisar de saída da tabela, um where existe pode ser melhor.