Power Query: como mesclar consultas (merge)

Juntar duas tabelas parece trivial, até o número dobrar sem explicação#

Toda vez que alguém precisa trazer o nome do cliente para dentro da tabela de vendas, ou o preço de custo para dentro do faturamento, aparece a mesma pergunta: como faço isso sem PROCV eterno na planilha? A resposta no Power BI é Power Query mesclar consultas (merge), o recurso que combina duas tabelas com base em uma coluna em comum e traz as colunas de uma para a outra. Parece simples, e é, quando você entende o que está acontecendo por baixo. O problema aparece quando a mesclagem roda, o visual mostra um total inflado e ninguém sabe por quê.

Neste artigo vou mostrar o passo a passo do merge no Power Query do jeito que a gente faz em projeto real: escolher a chave certa, entender cada tipo de junção, expandir só o que interessa e evitar as duas armadilhas que mais estragam relatório, a duplicidade de linhas e a perda de desempenho. Vou incluir o código M de cada etapa, porque quem lê o M entende o que a interface esconde.

O merge combina duas tabelas por uma chave e o M usa Table.NestedJoin#

Antes do passo a passo, vale fixar o conceito. Mesclar não é o mesmo que anexar (append). Anexar empilha linhas de tabelas com o mesmo formato, uma embaixo da outra. Mesclar cruza tabelas lado a lado: você pega a tabela A, encontra as linhas correspondentes na tabela B por uma coluna comum e traz as colunas de B para dentro de A.

Na interface do Power Query, você faz isso pelo botão Mesclar Consultas, na guia Página Inicial. Mas por baixo o Power Query gera uma linha de código na linguagem M com a função Table.NestedJoin. Entender essa função ajuda a resolver problemas que a interface não explica bem. A sintaxe padrão é esta:

Table.NestedJoin(
    Vendas,                 // tabela da esquerda
    {"CodClientE"},         // coluna-chave da esquerda
    Clientes,               // tabela da direita
    {"CodCliente"},         // coluna-chave da direita
    "DadosCliente",         // nome da coluna aninhada criada
    JoinKind.LeftOuter      // tipo de junção
)

Repare no penúltimo argumento: Table.NestedJoin cria uma coluna nova, do tipo tabela, com as linhas correspondentes de Clientes aninhadas dentro de cada linha de Vendas. Ela não expande nada sozinha. A expansão é uma segunda etapa, e é aí que muita gente tropeça. Guarde isso: o merge aninha, a etapa seguinte expande.

Power Query mesclar consultas (merge): o passo a passo que não quebra o resultado#

Vamos ao processo prático. Suponha que você tem uma consulta Vendas e quer trazer o nome e a cidade de cada cliente, que estão na consulta Clientes.

1. Garanta que as duas consultas já existem no editor. Ambas precisam estar carregadas no Power Query (não necessariamente carregadas no modelo). Uma pode ser conexão apenas.
2. Selecione a consulta base. Clique na consulta Vendas, que é a que vai receber as colunas novas. Ela será a tabela da esquerda.
3. Abra Mesclar Consultas. Na guia Página Inicial, use Mesclar Consultas para editar na mesma consulta, ou Mesclar Consultas como Novas para criar uma consulta separada e preservar a original.
4. Escolha a segunda tabela. No diálogo, selecione Clientes na lista suspensa.
5. Selecione a coluna-chave em cada tabela. Clique na coluna CodCliente em Vendas e na coluna correspondente em Clientes. As duas ficam destacadas. É esta coluna que casa as linhas.
6. Escolha o tipo de junção. No campo Tipo de Junção, defina como as linhas sem correspondência devem se comportar. O padrão é Externa à Esquerda, que costuma ser o certo para enriquecer uma tabela de fatos.
7. Confira o rodapé do diálogo. O Power Query mostra quantas das linhas da esquerda encontraram correspondência. Se todas casaram, ótimo. Se poucas casaram, você tem chave suja ou cadastro incompleto para investigar.
8. Confirme. O Power Query cria uma coluna nova, do tipo Table, no fim da tabela. Ela vem fechada, com o texto "Table" em cada célula.
9. Expanda as colunas. Clique no ícone de duas setas no cabeçalho dessa coluna nova. Marque só as colunas que você realmente precisa, por exemplo NomeCliente e Cidade. Desmarque o resto.
10. Trate o prefixo. Desmarque a opção "Usar nome da coluna original como prefixo" se você não quiser nomes como Clientes.Cidade. Renomeie depois se preferir clareza.

Pronto. As colunas da tabela da direita agora vivem dentro da tabela da esquerda. O código gerado tem duas linhas: o Table.NestedJoin que aninha e o Table.ExpandTableColumn que expande.

let
    Merge = Table.NestedJoin(
        Vendas, {"CodCliente"},
        Clientes, {"CodCliente"},
        "DadosCliente", JoinKind.LeftOuter
    ),
    Expandir = Table.ExpandTableColumn(
        Merge, "DadosCliente",
        {"NomeCliente", "Cidade"},
        {"NomeCliente", "Cidade"}
    )
in
    Expandir

Cada tipo de junção responde uma pergunta diferente#

O tipo de junção é a decisão mais importante do merge, e a interface esconde o impacto dela atrás de nomes técnicos. Cada tipo corresponde a um valor de JoinKind no M e define o que fazer com as linhas que não encontram par. A tabela abaixo resume:

Tipo na interface	Valor em M (JoinKind)	O que traz	Quando usar
Externa à Esquerda	JoinKind.LeftOuter	Todas as linhas da esquerda, com dados da direita quando houver	Enriquecer a tabela de fatos sem perder vendas
Externa à Direita	JoinKind.RightOuter	Todas as linhas da direita, com dados da esquerda quando houver	Menos comum, quando a direita é a base
Externa Completa	JoinKind.FullOuter	Todas as linhas das duas tabelas	Conciliar duas fontes e ver o que falta em cada lado
Interna	JoinKind.Inner	Só as linhas com correspondência nas duas	Manter apenas o que casa nas duas pontas
Anti à Esquerda	JoinKind.LeftAnti	Só as linhas da esquerda sem par na direita	Achar vendas com cliente inexistente no cadastro
Anti à Direita	JoinKind.RightAnti	Só as linhas da direita sem par na esquerda	Achar clientes que nunca compraram

As junções anti são as mais subestimadas. Quer saber quais notas fiscais têm código de produto que não existe na tabela de produtos? Um Anti à Esquerda resolve em segundos, sem fórmula nenhuma. Esse tipo de checagem costuma virar rotina em projetos sérios de engenharia de dados, porque é mais barato achar o problema na origem do que caçar o número errado no dashboard.

Uma dica prática: em dúvida entre Interna e Externa à Esquerda para uma tabela de fatos, prefira a Externa à Esquerda e depois investigue as linhas sem correspondência. A junção interna descarta silenciosamente as vendas sem cliente, e você só descobre quando o total não bate com a origem.

Duplicidade é o erro número um, e quase sempre vem da tabela da direita#

Aqui está a armadilha que mais derruba relatório. O merge multiplica linhas quando a tabela da direita tem mais de uma linha por chave. Se cada CodCliente aparece uma única vez em Clientes, uma venda casa com exatamente um cliente e o total de vendas continua igual. Mas se o mesmo CodCliente aparece duas vezes na direita (um cadastro duplicado, por exemplo), cada venda daquele cliente vira duas linhas, e o seu faturamento dobra.

A regra é simples de enunciar e fácil de esquecer:

• Se a chave é única na tabela da direita, o merge não muda a contagem de linhas da esquerda. Relação de um para um ou muitos para um.
• Se a chave se repete na direita, o merge multiplica linhas. Relação muitos para muitos, e o total infla.

Antes de confiar em qualquer merge, garanta que a chave é única na tabela da direita. Você pode conferir clicando com o botão direito na coluna-chave da direita e usando Remover Duplicatas, ou agrupando por ela para checar. Se houver duplicidade legítima que você não pode remover, trate antes do merge com Table.Distinct ou com um agrupamento (Table.Group) que consolide as linhas em uma só. Resolver a granularidade da chave antes de mesclar é o que separa um modelo confiável de um relatório que ninguém acredita. Se você quer o panorama maior de como organizar tudo isso, vale ler o guia completo de Power BI para empresas no Brasil.

Desempenho: query folding decide se o merge roda na fonte ou na sua máquina#

Merge é uma operação cara. Ele compara linhas das duas tabelas, e quanto maiores elas forem, mais memória e tempo consome. A boa notícia é que o Power Query, quando as condições permitem, empurra a junção para a fonte de dados. Esse mecanismo se chama query folding: em vez de trazer as duas tabelas inteiras para a sua máquina e cruzar localmente, o Power Query traduz o merge para uma consulta SQL (ou equivalente) e deixa o banco fazer o trabalho pesado.

Query folding acontece quando a fonte suporta, tipicamente bancos relacionais como SQL Server, PostgreSQL ou um data warehouse. Ele quebra quando você mistura fontes que não conversam entre si, por exemplo mesclar uma tabela de SQL Server com um arquivo Excel, ou quando alguma etapa anterior já impediu a tradução. Para saber se o folding está ativo, clique com o botão direito na etapa de merge e verifique se Exibir Consulta Nativa está disponível. Se estiver, o passo está sendo empurrado para a fonte. Se estiver cinza, o Power Query vai processar localmente.

Algumas práticas que ajudam o desempenho do merge:

Prática	Por que ajuda
Reduzir colunas antes de mesclar	Menos dados carregados na memória durante a junção
Filtrar linhas antes do merge	Menos linhas para comparar dos dois lados
Manter a fonte na mesma origem	Preserva o query folding e joga o trabalho para o banco
Expandir só as colunas necessárias	Evita arrastar dezenas de campos que ninguém usa
Garantir chave única na direita	Evita explosão de linhas e reprocessamento

Um detalhe honesto: nem sempre o merge no Power Query é a melhor escolha. Se as duas tabelas vão para o modelo de qualquer forma, muitas vezes é melhor deixá-las separadas e criar um relacionamento no modelo. Merge é ótimo para achatar dimensões pequenas dentro de uma fato ou preparar dados antes de carregar. Não é ferramenta para tudo. Essa decisão de arquitetura, mesclar na consulta ou relacionar no modelo, é um dos pontos que a gente sempre discute em projeto de Power BI, porque ela afeta desempenho e manutenção por anos.

Perguntas frequentes#

Qual a diferença entre mesclar e anexar consultas no Power Query?

Mesclar (merge) cruza duas tabelas lado a lado por uma coluna comum e traz colunas de uma para a outra, como um PROCV. Anexar (append) empilha linhas de tabelas com a mesma estrutura, uma embaixo da outra. Use merge para enriquecer, use append para consolidar históricos ou fontes iguais.

Por que meu total dobrou depois de mesclar as consultas?

Quase sempre porque a coluna-chave se repete na tabela da direita. Quando a chave não é única na direita, cada linha da esquerda casa com várias linhas e o merge multiplica os registros. Confira duplicatas na chave da tabela da direita e resolva a granularidade antes de mesclar.

O que significa a coluna com o texto "Table" que aparece depois do merge?

É a coluna aninhada que o Table.NestedJoin cria. Cada célula guarda as linhas correspondentes da tabela da direita, ainda fechadas. Você precisa clicar no ícone de duas setas no cabeçalho e expandir, escolhendo quais colunas trazer. Sem expandir, os dados ficam invisíveis.

Qual tipo de junção devo usar para trazer dados de cadastro para uma tabela de vendas?

Externa à Esquerda (JoinKind.LeftOuter) na maioria dos casos. Ela preserva todas as vendas mesmo quando o cliente não existe no cadastro, evitando perder linhas silenciosamente. Depois, use uma junção Anti à Esquerda para investigar as vendas que ficaram sem correspondência.

O merge no Power Query é bom para tabelas muito grandes?

Depende do query folding. Se as duas tabelas vêm da mesma fonte que suporta folding, como um banco relacional, o merge é traduzido para SQL e roda na fonte com bom desempenho. Se você mistura fontes ou já quebrou o folding, o merge processa localmente e pode ficar lento. Nesses casos, avalie criar um relacionamento no modelo.

Posso mesclar usando mais de uma coluna como chave?

Sim. No diálogo, segure Ctrl e selecione as colunas na ordem correspondente nas duas tabelas. No código M, você passa listas com vários nomes, como {"Ano","CodProduto"} dos dois lados. Isso é útil quando nenhuma coluna sozinha identifica a linha de forma única.

Fechamento#

Mesclar consultas no Power Query é uma das habilidades que mais rendem no dia a dia de quem trabalha com dados, e também uma das que mais causam erro quando feita no automático. Escolha a chave certa, entenda o tipo de junção, garanta unicidade na direita, expanda só o necessário e fique de olho no query folding. Com esses cinco cuidados, o merge deixa de ser fonte de número errado e vira ferramenta confiável.

Se a sua base já cresceu a ponto de o Power Query engasgar, ou se você desconfia que os totais do relatório não batem com o sistema de origem, fale com a gente. A Fynx ajuda a estruturar o ETL e o modelo do jeito certo, para o número nunca mais ficar sob suspeita.