UNION e UNION ALL em SQL: O que eles fazem e como eles são diferentes

Neste artigo, vamos explorar as cláusulas SQL UNION e UNION ALL. Aprenda o que eles fazem e quando usar cada um deles.

Eu já era analista há provavelmente quatro anos antes de saber da cláusula SQL UNION ALL. Eu usava regularmente UNION, mas nunca tinha ouvido falar de sua contraparte. Então, um dia, quando ouvi um colega de trabalho falando sobre isso. Pensei para mim mesmo: "Do que ele está falando? Isto é algo novo?" Então fiz o que qualquer bom analista faria e pesquisei no Google. Meu coração afundou. Provavelmente, em mais de uma ocasião, eu havia usado a cláusula incorreta em minhas análises.

Depois da faculdade, eu mesmo ensinei SQL. O resultado foi uma compreensão incompleta da sintaxe que eu estava usando. Como você está aprendendo, recomendo vivamente que faça cursos formais para que você possa ter certeza de que tem uma compreensão completa das consultas que está escrevendo. Uma ótima maneira de fazer isso é fazendo o SQL para Iniciantes curso. Não cometa os mesmos erros que eu cometi no início da minha carreira. Faça aulas com profissionais e adquira um sólido conhecimento fundacional de SQL.

Estou ficando um pouco à frente de mim mesmo. Vamos dar um passo atrás e falar sobre o que UNION e UNION ALL fazem em SQL.

UNIÃO

Haverá momentos em que um analista precisará combinar os resultados de múltiplas consultas. Isto pode ser porque os dados vivem em tabelas diferentes ou talvez você tenha consultas existentes que agora precisa fazer em uma só. Seja qual for o motivo, a solução mais simples é usar o UNION. Vamos ilustrar com um exemplo.

Exemplo nº 1 - UNION

Neste exemplo, vamos imaginar que estamos trabalhando na análise de alguns dados do site. Uma tabela com a qual estaremos trabalhando é chamada button_clicks. Esta tabela contém todos os eventos de clique que estamos acompanhando em nosso site. É o que parece:

Também estaremos trabalhando com uma tabela chamada: navigation_clicks. Esta tabela contém todos os eventos de cliques que ocorrem no menu de navegação do site. É o que parece:

Digamos que nosso gerente vem até nós e diz que eles precisam de uma lista de todos os cliques de botão no site. Isso é fácil o suficiente. Vamos simplesmente correr:

SELECT *
FROM button_clicks

Entretanto, eles voltam para nós alguns minutos depois e nos pedem para incluir os cliques de navegação em nosso relatório. Parece simples o suficiente, mas como fazemos isso? Usando a cláusula UNION. Para combinar os resultados destas duas consultas juntos, vamos correr:

SELECT *
FROM button_clicks
	
	UNION

SELECT *
FROM navigation_clicks

Como você pode ver, a cláusula UNION vai entre as duas consultas SELECT. A consulta em ambos os lados da cláusula UNION deve ser executada como uma consulta autônoma. Esta consulta retornará o seguinte:

O que fizemos foi pegar o resultado de duas consultas separadas e colocá-las uma em cima da outra. Vemos que as 4 primeiras linhas contêm os resultados da primeira consulta e as 5 filas seguintes contêm os resultados da segunda consulta.

Mas espere... nossas tabelas combinadas contêm 10 linhas, então por que só retornamos 9? Isto porque UNION irá remover duplicatas dos resultados. As duas primeiras fileiras da tabela button_clicks são exatamente os mesmos, portanto nosso UNION devolveu apenas um deles.

Renomeando Colunas em UNION

No resultado definido acima, observe os nomes das colunas. Na tabela button_clicks, a terceira coluna é etiqueta, mas na tabela navigation_clicks a terceira coluna é navigation_label. Quando utilizarmos UNION, os nomes das colunas virão dos nomes das colunas da primeira consulta, que é o que vemos acima. Se desejar, você pode sempre adicionar alias às colunas para renomeá-las ao seu gosto.

Por exemplo, se quisermos mudar o nome da terceira coluna para button_or_navigation_label, devemos correr:

SELECT user_id, 
	 timestamp,
       label AS button_or_navigation_label
FROM button_clicks
	
	UNION

SELECT user_id, 
	 timestamp,
       navigation_label AS button_or_navigation_label
FROM navigation_clicks

Exemplo #2 - Usando o mesmo número de colunas em UNION

Vamos caminhar por outro exemplo usando a UNION. Primeiro, faremos uma pequena modificação em nosso navigation_clicks mesa. Vamos acrescentar mais uma coluna para que nossa mesa agora se pareça com esta:

Se tentarmos executar nossa consulta original UNION novamente, teremos um erro que diz Each UNION query must have the same number of columns. Isto porque estamos selecionando todas as colunas da tabela de cada tabela, mas o número de colunas nas tabelas agora é diferente. Para corrigir isso, precisaremos nomear explicitamente as colunas que desejamos retornar. Além disso, o número de colunas retornadas por cada consulta deve ser o mesmo e o tipo deve corresponder. Se a terceira coluna na primeira consulta for uma string, a terceira coluna na outra consulta também deve ser uma string.

Para evitar qualquer erro, vamos correr:

SELECT user_id, 
 timestamp,
 label
FROM button_clicks
	
	UNION

SELECT user_id, 
 timestamp,
 	 navigation_label
FROM navigation_clicks

Isto retornará os mesmos resultados que nosso primeiro exemplo UNION.

Exemplo #3 - UNIÃO TODOS

Agora que entendemos UNION, vamos caminhar através de um exemplo usando UNION ALL. Como mencionado anteriormente, a UNION remove duplicatas de nossos resultados de consulta. A UNION ALL não fará isso.

Vamos continuar a construir a partir de nosso exemplo anterior. Nosso gerente chegou até nós pedindo um relatório que contém todos os botões e cliques de navegação no site. Confirmamos então que o relatório deve incluir as duplicatas.

Como você já sabe como usar UNION, você pode adivinhar como faríamos isso? É isso mesmo - vamos apenas substituir UNION por UNION ALL:

SELECT user_id, 
 timestamp,
 label
FROM button_clicks
	
	UNION ALL

SELECT user_id, 
 timestamp,
 	 navigation_label
FROM navigation_clicks

Há todas as 10 filas. Como você pode ver, UNION ALL preservou todos os resultados, mesmo que haja duplicatas.

Nossos exemplos incluíram apenas uma declaração UNION ou UNION ALL, mas não há limite para o número de consultas que vocês podem fazer juntos.

Apenas para um último exemplo, digamos que também queríamos incluir uma tabela chamada form_clicks. Não estamos preocupados com as duplicatas, portanto continuaremos usando UNION ALL:

SELECT user_id, 
 timestamp,
 label
FROM button_clicks
	
	UNION ALL

SELECT user_id, 
 timestamp,
 	 navigation_label
FROM navigation_clicks

UNION ALL

SELECT user_id, 
 timestamp,
 	 form_label
FROM form_clicks

Como você pode ver, é exatamente a mesma sintaxe; apenas continuamos a acrescentar à nossa consulta existente. Se você estiver interessado em saber mais sobre UNION ALL, não deixe de ler nosso artigo SQL Union All!

UNION vs. UNION ALL - Escolhendo o que usar

É importante entender que uma consulta usando UNION ALL vai correr mais rápido do que se você usasse UNION. Isto porque a cláusula UNION está ordenando os dados e removendo quaisquer duplicatas. Dependendo da quantidade de dados que você estiver consultando, isto poderia acrescentar uma quantidade decente de tempo de execução à sua consulta.

Quando você está decidindo qual cláusula usar, é tão simples quanto fazer a si mesmo a seguinte pergunta:

1. Preciso remover os valores duplicados?
   1. Em caso afirmativo, utilize UNION.
   2. Se não (ou se não importar), use UNION ALL.

Isso foi muito, então vamos levar algum tempo para rever! Tanto UNION quanto UNION ALL são cláusulas usadas para combinar múltiplas consultas em um único conjunto de resultados. UNION removerá as duplicatas, enquanto UNION ALL não. UNION ALL corre mais rápido por causa disso. Aqui está outro grande artigo sobre as operações do SQL Set para ajudar a reforçar e expandir o que você acabou de aprender.

Bom trabalho! Agora você tem um firme entendimento tanto de UNION quanto de UNION ALL e pode tomar uma decisão informada sobre qual usar em suas análises. Você já está vários passos à frente de onde eu estava quando eu estava aprendendo! Não deixe de conferir nossas SQL para Iniciantes curso e continuar sua jornada para se tornar um escritor especializado em SQL.