Mehrere Abfragen zusammenzuführen ist in SQL ein Standardfall, aber UNION ALL wird oft unterschätzt. Die Anweisung kombiniert Resultsets ohne Dubletten-Entfernung und ist damit häufig schneller und fachlich korrekter als UNION, wenn doppelte Zeilen ausdrücklich erlaubt oder sogar gewünscht sind.
Gerade in Reporting, Event-Logs, Feeds oder beim Vereinheitlichen ähnlicher Datenquellen spart eine saubere Wahl zwischen UNION und UNION ALL unnötige Sortierung, Missverständnisse im Team und schlecht nachvollziehbare Abfragepläne.
Was macht SQL UNION ALL genau?
UNION ALL hängt die Ergebnisse mehrerer SELECT-Abfragen untereinander. Im Unterschied zu UNION entfernt die Datenbank dabei keine Dubletten, sondern übernimmt alle Zeilen in das Endergebnis.
Das klingt nach einem Detail, ist aber semantisch wichtig. UNION bedeutet: „Kombiniere und dedupliziere.“ UNION ALL bedeutet: „Kombiniere exakt alles.“ Wenn zwei Teilabfragen dieselbe Zeile liefern, bleibt sie bei UNION ALL zweimal erhalten. Genau das ist bei Transaktionen, Logs, Bestellungen oder Messwerten oft gewollt.
Ein zweiter zentraler Punkt ist die Struktur. Alle beteiligten SELECT-Abfragen müssen dieselbe Anzahl an Spalten liefern, und die Datentypen müssen zueinander passen. Die Spaltennamen des Gesamtergebnisses stammen in der Praxis aus der ersten Teilabfrage. Wer hier unsauber arbeitet, erzeugt schnell schwer lesbare Resultsets.
SELECT id, email, 'kunden' AS quelle
FROM kunden
UNION ALL
SELECT id, email, 'leads' AS quelle
FROM leads;Dieses Muster ist nützlich, wenn ähnliche Tabellen gemeinsam ausgewertet werden sollen. Für spätere Filter, Sortierung oder Pagination wird die Abfrage oft noch in eine Unterabfrage oder einen CTE verpackt, ähnlich wie bei sauber strukturierten CTE-Strukturen.
Wann ist UNION ALL besser als UNION?
Performance und fachliche Korrektheit sprechen oft für UNION ALL. Wenn doppelte Zeilen nicht entfernt werden sollen, ist UNION nicht nur teurer, sondern schlicht die falsche Aussage an die Datenbank.
UNION muss das Gesamtergebnis auf Gleichheit prüfen. Je nach Datenbanksystem geschieht das typischerweise über Sortierung, Hashing oder interne Zwischenschritte. Dieser Aufwand kostet CPU, Speicher und bei großen Resultsets auch Zeit. UNION ALL kann die Daten dagegen direkt zusammenführen.
Fachlich ist das noch wichtiger. Wer etwa Bestellungen aus zwei Vertriebskanälen zusammenführt, möchte in der Regel jede Bestellung sehen, auch wenn zufällig zwei Datensätze dieselben Werte in allen ausgewählten Spalten haben. Mit UNION würde in so einem Fall stillschweigend Information verloren gehen. Das ist kein Optimierungsproblem mehr, sondern ein Datenfehler.
| Aspekt | UNION | UNION ALL |
|---|---|---|
| Dubletten | werden entfernt | bleiben erhalten |
| Aufwand | höher durch Prüfung | geringer |
| Typischer Einsatz | Mengenlogik ohne Wiederholungen | Rohdaten, Events, Reports |
| Fehlerrisiko | versehentlicher Datenverlust möglich | eher zu viele als zu wenige Zeilen |
Wenn Dubletten wirklich unerwünscht sind, sollte UNION bewusst gewählt werden. Wenn sie erlaubt sind oder eine fachliche Bedeutung tragen, ist UNION ALL fast immer die sauberere Entscheidung.
Welche Regeln gelten für Spalten, Typen und Sortierung?
Bei Resultsets aus mehreren Teilabfragen müssen Form und Bedeutung zusammenpassen. SQL prüft nicht, ob Spalten fachlich zusammengehören, sondern nur, ob Anzahl und Typen kompatibel sind.
Ein häufiger Fehler ist, Spalten in unterschiedlicher Reihenfolge zu liefern. Dann bleibt die Abfrage zwar technisch gültig, aber die Werte landen in den falschen Spalten. Ebenso problematisch sind implizite Typkonvertierungen, etwa zwischen Integer, Text und Datum. Je nach Datenbank kann das funktionieren, Warnungen erzeugen oder scheitern.
Sortierung gilt außerdem nicht pro Teilabfrage, sondern für das Gesamtergebnis. Wer ein finales ORDER BY braucht, setzt es ans Ende der gesamten UNION ALL-Kette. Dabei sollte man sich auf die ausgegebenen Spalten oder deren Aliase beziehen.
SELECT created_at, message, 'app' AS source
FROM app_logs
UNION ALL
SELECT created_at, message, 'worker' AS source
FROM worker_logs
ORDER BY created_at DESC;Wenn Spalten semantisch unterschiedlich heißen, helfen klare Aliase. Das verbessert Lesbarkeit, Reviewbarkeit und spätere Weiterverarbeitung. Gerade bei größeren Datenabfragen spart eine klare Struktur ähnlich viel Zeit wie sauber gewählte gekapselte Abfragen.
- Prüfe zuerst, ob alle Teilabfragen dieselbe Spaltenanzahl liefern.
- Ordne die Spalten in jeder Teilabfrage in exakt derselben Reihenfolge an.
- Setze Aliase dort, wo Spalten fachlich gleich gemeint sind, aber anders heißen.
- Nutze
ORDER BYnur am Ende des Gesamtergebnisses, nicht zwischen den Teilabfragen. - Entscheide bewusst, ob Dubletten fachlich erlaubt, gewünscht oder verboten sind.
Typische Einsatzfälle für UNION ALL im Alltag
Datenquellen mit gleichem Schema lassen sich mit UNION ALL sehr direkt zusammenführen. Besonders praktisch ist das bei Archivtabellen, Multi-Tenant-Reports, Event-Streams oder beim Zusammenführen historischer und aktueller Daten.
Ein klassischer Fall ist eine aktive Tabelle plus Archiv. Statt Daten vor einer Auswertung erst physisch zu verschieben oder in der Anwendung zusammenzubauen, kann SQL beide Quellen in einer Abfrage liefern. Das hält Logik näher an den Daten und reduziert unnötige Schleifen im Anwendungscode.
Auch bei Monitoring- oder Logging-Daten ist UNION ALL passend. Doppelte Einträge sind dort oft echte Ereignisse und keine Dubletten im fachlichen Sinn. Wer stattdessen dedupliziert, verfälscht Metriken, Fehlerraten oder Volumina. In solchen Szenarien lohnt außerdem ein Blick auf Query-Pläne, wenn Abfragen auf großen Tabellen langsamer werden.
Aktive und archivierte Bestellungen gemeinsam auswerten
Wenn aktuelle und alte Daten getrennt gespeichert werden, ist UNION ALL oft die direkteste Auswertungslösung. So bleibt die Anwendungslogik schlank, während die Datenbank die Zusammenführung übernimmt.
SELECT order_id, customer_id, total_cents, created_at
FROM orders_current
WHERE created_at >= DATE '2024-01-01'
UNION ALL
SELECT order_id, customer_id, total_cents, created_at
FROM orders_archive
WHERE created_at >= DATE '2024-01-01';Diese Form ist klarer als zwei getrennte Datenbankabfragen im Backend, die später manuell gemischt werden. Vor allem bei Pagination, Aggregation oder Exporten bleibt die Abfrage so konsistent.
Welche Fehler treten bei UNION ALL besonders oft auf?
Die meisten Probleme mit UNION ALL entstehen nicht durch die Syntax, sondern durch falsche Annahmen. Typisch sind vertauschte Spalten, unpassende Datentypen und ein unklarer Umgang mit Dubletten.
Ein häufiger Denkfehler lautet: „Die beiden Abfragen sehen ähnlich aus, also passen sie zusammen.“ Das reicht nicht. Schon eine andere Spaltenreihenfolge kann Werte semantisch verschieben. Ebenso problematisch ist das Mischen von Brutto- und Netto-Werten, UTC- und Lokalzeit oder unterschiedlichen Statusmodellen in einer gemeinsamen Ergebnismenge.
Auch Pagination ist heikel. Wer LIMIT und OFFSET ohne stabiles ORDER BY auf ein kombiniertes Resultset anwendet, bekommt leicht wechselnde Seiteninhalte. Bei großen Datenmengen ist cursor-basierte Pagination oft robuster, besonders wenn mehrere Quellen parallel einfließen, ähnlich wie bei sauber geplantem Cursor-Paging.
Schließlich sollte UNION ALL nicht als Ersatz für einen passenden JOIN missverstanden werden. Wenn Datensätze nebeneinander angereichert werden sollen, ist meist ein Join korrekt. UNION ALL gehört zu vertikaler Kombination, nicht zu relationaler Verknüpfung.
Wann sollte trotzdem lieber UNION verwendet werden?
UNION ist sinnvoll, wenn das Endergebnis eine echte Menge ohne Wiederholungen darstellen soll. Das trifft etwa auf Listen von eindeutigen Kategorien, IDs oder Tags zu, sofern Dubletten fachlich keine Rolle spielen.
Die Entscheidung sollte aber aus dem Datenmodell kommen, nicht aus Gewohnheit. Wer Dubletten nur „vorsichtshalber“ entfernt, verschleiert häufig ein fachliches Problem oder ein unpräzises Query-Design.
Wie lässt sich UNION ALL sauber und wartbar einsetzen?
Wartbarkeit entsteht bei UNION ALL vor allem durch klare Benennung, einheitliche Spalten und kleine, verständliche Teilabfragen. Je mehr Quellen beteiligt sind, desto wichtiger wird Konsistenz.
In produktiven Projekten lohnt es sich, jede Teilabfrage für sich lesbar zu halten und gemeinsame Bedeutung explizit zu machen. Dazu gehören stabile Aliase, gleiche Typen und dokumentierte Filterlogik. In PostgreSQL, MySQL oder SQLite funktioniert das Grundprinzip ähnlich, auch wenn Optimizer und Typregeln sich im Detail unterscheiden können.
Praktisch ist außerdem, die kombinierte Abfrage zunächst fachlich zu formulieren und erst danach zu optimieren. Erst wenn klar ist, dass doppelte Zeilen gewollt sind, wird UNION ALL zur richtigen Wahl. Danach helfen Indizes, Filter vor der Kombination und ein Blick auf den Ausführungsplan, falls das Resultset groß wird.
Unterm Strich ist UNION ALL kein Spezialfall, sondern ein präzises Werkzeug. Wer es bewusst einsetzt, erhält oft schnellere Abfragen und gleichzeitig korrekt abgebildete Daten. Genau deshalb sollte nicht automatisch UNION der Standard sein, sondern die fachlich passende Operation.
UNION ALL ist die richtige Wahl, wenn mehrere Abfragen vollständig und ohne Dubletten-Prüfung zusammengeführt werden sollen. Das verbessert oft die Performance und verhindert gleichzeitig, dass fachlich relevante Zeilen stillschweigend verschwinden. Entscheidend sind saubere Spaltenstrukturen, ein bewusstes Verständnis von Dubletten und ein finales ORDER BY nur dort, wo das Gesamtergebnis stabil sortiert werden muss. Wer diese Regeln beachtet, baut kombinierte SQL-Abfragen robuster und leichter wartbar.
