O que são unificações tardias e por que elas estragam suas queries quando você não entende como funcionam
Unificação tardia é quando o otimizador de consulta decide adiar a junção de tabelas ou a execução de um UNION para o final do plano de execução, em vez de processar logo de cara. A ideia teórica é boa. Na prática, depende inteiramente do tamanho dos dados intermediários e de quantos índices você tem disponíveis no momento da execução.
Entendendo o conceito na prática das unificações tardias
Vou explicar da forma mais direta possível. Suponha que você tenha uma consulta que envolve UNION entre duas tabelas grandes e depois faz um JOIN com uma terceira. O otimizador pode decidir fazer primeiro o JOIN entre a tabela grande e a terceira, reduzindo o volume, e só então aplicar o UNION. Isso é unificação tardia. Se ele fizer o contrário e processar o UNION primeiro, você pode ter milhões de linhas sendo manipuladas desnecessariamente. O problema é que o otimizador nem sempre acerta. Ele trabalha com estatísticas, e estatísticas desatualizadas são a principal causa de decisões erradas. Já vi cenários onde o UNION era executado primeiro porque as estatísticas estavam com seis meses de defasagem, gerando um plano que levava 47 minutos para rodar. Atualizei as estatísticas e caiu para 12 segundos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma coisa que poucos mencionam: unificação tardia não é apenas sobre UNION. Em bancos como SAP HANA, o conceito se aplica também a joins que poderiam ser adiantados ou adiados dependendo da cardinalidade estimada. O mecanismo chama-se "late materialization" em alguns contextos e "union postponement" em outros. São coisas relacionadas mas distintas. Aqui vai um insight que provavelmente vai surpreender quem está começando: unificação tardia não é inerentemente ruim. O que é ruim é confiar cegamente no plano escolhido pelo otimizador sem verificar se ele faz sentido para o seu workload específico. Eu gosto de usar EXPLAIN PLAN ou equivalente para ver o plano real antes de validar qualquer performance.
Um cenário onde unificação tardia falha completamente é quando você tem uma tabela com bilhões de linhas e faz UNION com outra de poucas centenas. Se o otimizador adiar a unificação esperando que o join reduza o volume, mas o join na verdade expande (porque é um LEFT JOIN com muitos nulos), você termina processando o UNION em billions de linhas em vez de milhares. Isso acontece com frequência em relatórios financeiros onde há muitos registros órfãos. Minha solução prática para esse problema foi criar um hint forçando a ordem de execução no código SQL. Ficou algo como usar /*+ LEADING */ no Oracle ou FORCE PLAN no HANA, dependendo do banco. O código ficou feio mas rodou em 3 segundos ao invés de 40 minutos. Desde então, faço um review do plano de execução em toda query que envolva UNION com grandes volumes.
Outra armadilha comum: unificação tardia funciona bem quando as tabelas envolvidas têm selectividades altas nos predicados de filtro. Mas se os filtros forem muito seletivos em uma das partes do UNION e quase não filtrarem na outra, o otimizador pode escolher mal. Nesses casos, dividir a query em duas partes e juntar os resultados em código é mais rápido do que depender do otimizador. Não existe fórmula mágica para saber quando o otimizador vai escolher unificação tardia. A melhor abordagem é entender o padrão dos seus dados, manter estatísticas atualizadas e nunca assumir que o plano gerado é o melhor. Teste, meça, ajuste. É simples mas exige disciplina.
