Ambos operadores apilan los resultados de dos consultas una encima de la otra, por lo que SQL UNION vs UNION ALL podría parecer una elección menor. No lo es. Una palabra extra cambia tanto el resultado como el esfuerzo que tiene que trabajar la base de datos.

Ejecutamos todas las consultas aquí en SQLite 3.50 y los resultados y tiempos mostrados provienen de esas ejecuciones. El comportamiento básico es SQL estándar en las principales bases de datos. Los tiempos, sin embargo, variarán según su propia base de datos, datos y hardware, así que trate el nuestro como ejemplo.

La respuesta corta

UNION combina dos conjuntos de resultados y devuelve solo filas distintas. UNION ALL los combina y devuelve todo, incluidos los duplicados. Esa es toda la diferencia, y el resto de este artículo trata sobre por qué es importante.

UNION vs UNION TODOS lado a lado

Los datos de muestra

Imagine una tienda que mantiene los pedidos en línea y en la tienda en mesas separadas. Tenga en cuenta que Asha tiene dos pedidos idénticos en línea y un pedido idéntico en la tienda.

CREATE TABLE online_orders (customer TEXT, total INT);
CREATE TABLE store_orders (customer TEXT, total INT);

INSERT INTO online_orders VALUES ('Asha',100), ('Ben',200), ('Asha',100);
INSERT INTO store_orders VALUES ('Asha',100), ('Dev',300);

ver la diferencia

SELECT customer, total FROM online_orders
UNION
SELECT customer, total FROM store_orders;

-- Asha | 100
-- Ben  | 200
-- Dev  | 300

SELECT customer, total FROM online_orders
UNION ALL
SELECT customer, total FROM store_orders;

-- Asha | 100
-- Ben  | 200
-- Asha | 100
-- Asha | 100
-- Dev  | 300

Cinco filas de entrada se convirtieron en tres con UNION y las cinco quedaron con UNION ALL. Dos cosas a tener en cuenta:

• UNION eliminó duplicados de todo el resultado, incluidos los de la primera tabla. No se trata sólo de comparar entre tablas.
• Una fila cuenta como duplicada solo cuando todas las columnas seleccionadas coinciden.

Cuando realmente desea una lista distinta, UNION es exactamente la correcta. Esto le brinda a cada cliente que compró a través de cualquiera de los canales:

SELECT customer FROM online_orders
UNION
SELECT customer FROM store_orders;

-- Asha
-- Ben
-- Dev

El error total equivocado

Ésta es la razón por la que la elección realmente importa. Supongamos que desea ingresos totales. Los pedidos anteriores suman 800. Vea lo que ofrece cada operador:

SELECT SUM(total) FROM (
  SELECT total FROM online_orders
  UNION
  SELECT total FROM store_orders
);
-- 600

SELECT SUM(total) FROM (
  SELECT total FROM online_orders
  UNION ALL
  SELECT total FROM store_orders
);
-- 800

La versión UNION tiene un error de 200. Debido a que seleccionamos solo la columna total, tres pedidos separados de 100 rupias parecían duplicados y se colapsaron en uno. No hay ningún mensaje de error y 600 parece un número perfectamente creíble. Este tipo de error silencioso puede permanecer en un informe financiero durante meses.

Reglas que ambos deben seguir.

Ambos operadores tienen los mismos requisitos:

1. Cada SELECT debe devolver el mismo número de columnas.
2. Las columnas coinciden por posición, no por nombre, así que manténgalas en el mismo orden.
3. Los tipos de datos en cada posición deben ser compatibles.
4. Los nombres de las columnas de resultados provienen del primero SELECT.
5. ORDER BY va al final y se aplica a todo el resultado.

Romper la primera regla da lugar a un error. Aquí está el mensaje de SQLite:

SELECT customer, total FROM online_orders
UNION
SELECT customer FROM store_orders;

-- SELECTs to the left and right of UNION do not have
-- the same number of result columns

La segunda regla es más peligrosa porque puede fallar sin cometer un error. Si intercambia dos columnas del mismo tipo, como first_name y last_name, la consulta se ejecuta y los datos resultan incorrectos. SQLite también es relajado en cuanto a los tipos, mientras que las bases de datos como PostgreSQL son más estrictas y pueden requerir una definición explícita CAST.

Etiquetar la fuente

Un truco muy práctico es añadir una columna constante que muestre de dónde procede cada fila. Debido a que la etiqueta es diferente, las filas de tablas diferentes ya no se pueden tratar como duplicados entre sí.

SELECT customer, total, 'online' AS channel FROM online_orders
UNION ALL
SELECT customer, total, 'store' FROM store_orders
ORDER BY customer, channel;

-- Asha | 100 | online
-- Asha | 100 | online
-- Asha | 100 | store
-- Ben  | 200 | online
-- Dev  | 300 | store

Una vez que tus datos tengan una etiqueta, puedes agruparlos para reportar ventas por canal, usando GROUP BY. Si necesita combinar varios pasos, envuelva la unión en un CTE para que sea legible.

Rendimiento: lo que pasó en nuestra prueba

Para eliminar duplicados, la base de datos tiene que comparar filas, generalmente ordenándolas o aplicando hash. UNION ALL puede omitir este paso. Creamos dos tablas con 500.000 filas cada una, que contenían números aleatorios del 0 al 50.000, por lo que había muchos duplicados. Ejecutamos cada consulta varias veces y mantuvimos el mejor tiempo.

Primero, contamos los resultados, de modo que el tiempo dedicado a enviar filas a nuestro programa no afectó la comparación:

La enorme brecha se debe en parte a que SQLite puede calcular ese recuento sin leer cada fila, así que no lo lea como “miles de veces más rápido”. Sin embargo, muestra la idea central: UNION tenía que hacer un trabajo real y UNION ALL no.

Luego recuperamos todas las filas en Python y el resultado cambió:

En este caso, UNION ALL tardó más porque entregó veinte veces más filas. La deduplicación no es lo que lo frenó. Manejar un millón de filas lo fue. Entonces, la regla honesta es que UNION ALL es más barato de calcular para la base de datos, pero el tamaño del resultado también importa. Muchos gráficos en línea reducen esto a “UNION ALL es siempre más rápido”, y nuestra prueba muestra por qué no es tan simple.

Tampoco elijas basándose únicamente en la velocidad. Elija primero al operador que dé la respuesta correcta y luego sintonice. Si una consulta es lenta, lea nuestra guía para optimización de consultas SQL.

Cuando usar cada

Utilice UNION ALL cuando:

• Está fusionando datos de tablas similares, como particiones mensuales.
• Calculará los totales o recuentos después.
• Sabes que las entradas no pueden superponerse.
• Los duplicados son significativos, como en los registros o registros de auditoría.

Utilice UNION cuando:

• Necesita una lista única, como cada dirección de correo electrónico en dos sistemas.
• Las fuentes superpuestas contienen el mismo hecho más de una vez.

Trate UNION ALL como predeterminado y utilice UNION deliberadamente. Agregar una cláusula WHERE a cada rama, para filtrar temprano, ayuda a ambos.

INTERSECTAR y EXCEPTAR

Dos operadores de conjuntos relacionados responden a preguntas diferentes. Ambos siguen las mismas reglas de columna:

SELECT customer FROM online_orders
INTERSECT
SELECT customer FROM store_orders;
-- Asha  (bought in both channels)

SELECT customer FROM online_orders
EXCEPT
SELECT customer FROM store_orders;
-- Ben   (online only)

Oracle ha utilizado tradicionalmente MINUS en lugar de EXCEPT, y el soporte para estos operadores varía un poco según la base de datos y la versión.

UNIÓN vs UNIRSE

A menudo se confunden, pero combinan datos en diferentes direcciones:

Errores comunes

• Usar UNION por costumbre. Puede costarle velocidad o eliminar filas válidas.
• Seleccionar muy pocas columnas. Omitir un ID hace que las distintas filas parezcan idénticas.
• Orden de columnas no coincidente. Los valores pueden aparecer en la columna incorrecta sin ningún error.
• Añadiendo ORDER BY a cada rama. Ordenar una vez, al final.
• Usar UNION para parchear una unión incorrecta. Si aparecen duplicados debido a una unión, corrija la unión.
• Asumiendo el orden de los resultados. Sin ORDER BY, el orden de las filas no está garantizado para ninguno de los operadores.

Conclusión

Haga una pregunta cada vez: ¿filas idénticas son el mismo hecho o son hechos separados? Si están separados o si es imposible superponerlos, utilice UNION ALL. Si necesita una lista única, utilice UNION. Para verificar sus propios informes, busque en su código UNION cerca de SUM o COUNT y confirme que esos totales realmente sean correctos.

Preguntas frecuentes

sigue aprendiendo