Aggregation und Gruppierung in SQL

Eine Aggregatfunktion fasst Werte aus vielen Zeilen zu einem Ergebnis zusammen. Oracle nennt sie auch Gruppenfunktion. Ohne GROUP BY behandelt eine Aggregatabfrage alle Zeilen, die WHERE passieren, als eine Gruppe und gibt eine zusammenfassende Zeile zurück.

Beginne mit Daten, die du prüfen kannst

Jede Zeile in orders ist eine Bestellung. Die numerischen Spalten unten enthalten ganze Zahlen; order_id ist der Primärschlüssel. Datumswerte werden in SQLite als ISO-Text und in PostgreSQL mit dem Typ DATE gespeichert.

Wähle die Kennzahl

SUM(amount) addiert die Beträge. AVG(amount) ergibt ihr arithmetisches Mittel. MIN(amount) ermittelt den kleinsten und MAX(amount) den größten Betrag. Du kannst alle vier in einer Abfrage anfordern:

SELECT SUM(amount) AS total, AVG(amount) AS avg_amount, MIN(amount) AS smallest, MAX(amount) AS largest FROM orders;

Das Ergebnis ist eine Zeile: Summe 780, Durchschnitt 97,5, kleinster Wert 30 und größter Wert 200. Addiere die acht Beträge, um 780 zu erhalten, und teile dann durch acht für 97,5. Jede Funktion verarbeitet dieselben acht Eingabezeilen. Aussagekräftige Aliase nach AS machen die Ausgabeüberschriften nützlich; eine erzeugte Überschrift wie sum sagt wenig darüber aus, was addiert wurde.

Filtere vor der Berechnung

Um Bestellungen aus East zusammenzufassen, schreibe SELECT COUNT(*) AS orders, SUM(amount) AS total FROM orders WHERE region = 'East';. Der Filter behält die Beträge 120, 45 und 95. Die Abfrage gibt drei Bestellungen und eine Summe von 260 zurück. WHERE wählt die Eingabezeilen aus, bevor ein Aggregat berechnet wird.

Ein Aggregat kann auch einen berechneten Ausdruck als Argument nehmen. In einer Tabelle mit quantity und unit_price ermittelt SUM(quantity * unit_price) zunächst den Umsatz jeder Zeile und addiert ihn dann. Zwei Zeilen, zwei Artikel zu 5 und drei Artikel zu 10, tragen 10 und 30 bei, zusammen 40. SUM(quantity) * SUM(unit_price) multipliziert dagegen 5 mit 15 und ergibt 75. Steht die Berechnung innerhalb von SUM, bleibt jede Menge dem passenden Preis zugeordnet.

Lies Extremwerte richtig

MIN(order_date) ist 2026-01-05 und MAX(order_date) ist 2026-03-21. Datumswerte und ISO-Datumstext werden chronologisch sortiert. Text wie '03/21/2026' folgt der Zeichenreihenfolge, die nicht zuverlässig der Datumsreihenfolge entspricht. Auch Extremwerte bei Text folgen der Sortierfolge der Datenbank, also ihren Regeln zum Vergleichen von Text. Hier sind die Extremwerte der Kundennamen 'Ana' und 'Eli'; unterschiedliche Groß- und Kleinschreibung kann die Textsortierung verändern.

MAX(amount) gibt einen Betrag zurück, nicht die ganze Bestellung, die ihn enthält. Um einen Kunden mit einer größten Bestellung anzuzeigen, verwende SELECT customer, amount FROM orders ORDER BY amount DESC LIMIT 1;. PostgreSQL lehnt eine gewöhnliche Spalte customer neben MAX(amount) ohne passende Gruppierung ab. SQLite hat eine Sonderregel für ein einzelnes MIN oder MAX, die eine benachbarte Spalte aus der Zeile mit dem Extremwert zurückgeben kann; bei gleichen Extremwerten wird aber weiterhin eine Regel für den Gleichstand benötigt.

„Wie viele?“ kann sich auf Zeilen, erfasste Werte oder unterschiedliche Werte beziehen. Das sind verschiedene Zählweisen, auch wenn sie in einer kleinen Tabelle zufällig dieselbe Zahl ergeben.

Drei Formen von COUNT

In der Bestelltabelle lauten die Regionen East, West, East, North, West, East, North und NULL. SELECT COUNT(*) AS order_rows, COUNT(region) AS with_region, COUNT(DISTINCT region) AS regions FROM orders; gibt 8, 7 und 3 zurück. Die wiederholten Regionsnamen werden bei COUNT(region) einzeln gezählt, aber jeder Name trägt nur einmal zur Anzahl unterschiedlicher Werte bei.

Für „Wie viele verschiedene Kunden haben bestellt?“ verwende COUNT(DISTINCT customer). Ana, Ben und Chen kommen jeweils zweimal vor, Dara und Eli jeweils einmal, die Antwort lautet also fünf Kunden. COUNT(customer) gibt acht zurück, weil jede Bestellung einen Kunden nennt. Es zählt Bestellzeilen mit Kundennamen, nicht Personen.

Eine erfasste Null zählt mit

Die Rabatte sind 10, NULL, 5, NULL, 0, NULL, 15 und NULL. COUNT(discount) gibt vier zurück. Die Null erfasst einen bekannten Wert und zählt genauso wie 10, 5 und 15. Eine leere Zeichenkette ist in SQLite und PostgreSQL ebenfalls ein Wert; Oracle behandelt eine leere Zeichenkette als NULL.

Ziehe die Anzahl der Werte ohne NULL von der Zeilenanzahl ab, um fehlende Einträge zu zählen: SELECT COUNT(*) - COUNT(region) AS missing_region FROM orders; gibt eins zurück. Das funktioniert, weil beide Zählungen genau dieselben Eingabezeilen verwenden.

DISTINCT-Listen und Anzahlen unterschiedlicher Werte

SELECT DISTINCT region FROM orders; listet East, West, North und eine NULL-Zeile auf. Die Abfrage soll unterschiedliche Werte zurückgeben, und NULL bleibt in dieser Liste. COUNT(DISTINCT region) gibt drei zurück, weil die Zählung NULL ignoriert. Schließe nicht durch Zählen einer Liste auf die Anzahl unterschiedlicher Werte, ohne zu entscheiden, ob ihre NULL-Zeile dazugehört.

DISTINCT kann auch innerhalb von SUM oder AVG stehen. Die Mengen sind 2, 1, 3, 4, 1, 2, 5 und 1. Ihre gewöhnliche Summe ist 19. SUM(DISTINCT quantity) behält nur 1, 2, 3, 4 und 5 und ergibt 15. Wiederholte Mengen stehen gewöhnlich für tatsächliche zusätzliche Verkäufe. Entfernst du sie, ändert sich die Kennzahl; doppelte Datensätze werden dadurch nicht korrigiert.

Kombinationen in zwei Schritten zählen

Erstelle für unterschiedliche Paare aus Region und Kunde zunächst eine Liste unterschiedlicher Werte:

SELECT COUNT(*) FROM (SELECT DISTINCT region, customer FROM orders) AS pairs;

Die innere Abfrage gibt fünf Paare zurück: East/Ana, East/Dara, North/Chen, West/Ben und NULL/Eli. Das äußere COUNT(*) zählt diese fünf Zeilen einschließlich NULL/Eli. Diese Form funktioniert in SQLite und PostgreSQL. MySQL akzeptiert auch COUNT(DISTINCT region, customer), aber diese Form schließt Kombinationen mit NULL aus und kann daher eine andere Frage beantworten. In SQLite und PostgreSQL ist die durch Kommas getrennte Form unzulässig.

Eine Zählung gibt niemals NULL zurück. SELECT COUNT(*) FROM orders WHERE region = 'South'; gibt eine zusammenfassende Zeile mit null zurück, weil es keine passenden Bestellungen gibt.

NULL bedeutet, dass ein Wert fehlt oder unbekannt ist. Es verändert, welche Werte in ein Aggregat eingehen. Daher kann eine Summe oder ein Durchschnitt gültiges SQL sein und dennoch etwas anderes messen als beabsichtigt.

Bestimme den Nenner

Angenommen, scores enthält Ana 80, Ben NULL, Chen 70 und Dara 90. SUM(score) ist 240, COUNT(score) ist drei und COUNT(*) ist vier. AVG(score) ist 80: Die drei erfassten Punktzahlen ergeben zusammen 240 und werden durch drei geteilt.

Die fünf Standardaggregate ignorieren NULL-Argumente. COUNT(*) zählt jede Zeile, weil es kein Spaltenargument auswertet. MIN(score) ist 70 und MAX(score) ist 90; NULL wird weder zur kleinsten noch zur größten Punktzahl. Das unterscheidet sich vom Sortieren, bei dem NULL-Werte an einem Ende des Ergebnisses stehen: bei aufsteigender Sortierung in SQLite zuerst, in PostgreSQL zuletzt.

Für einen von Hand berechneten Durchschnitt wird die Anzahl der Werte ohne NULL benötigt: 1.0 * SUM(score) / NULLIF(COUNT(score), 0). Der Dezimaloperand erhält Nachkommastellen im Ergebnis, und NULLIF macht einen Divisor von null zu NULL. Eine Division durch COUNT(*) würde 60 ergeben und die fehlende Punktzahl damit wie null behandeln.

Entscheide, was ein Ersatzwert bedeutet

COALESCE gibt das erste Argument zurück, das nicht NULL ist. Wenn Ben noch nicht bewertet wurde, lass die Punktzahl fehlen und berechne den Durchschnitt der bekannten Ergebnisse. Wenn eine versäumte Prüfung als NULL erfasst ist, aber als null zählen muss, bildet AVG(COALESCE(score, 0)) den Durchschnitt von 80, 0, 70 und 90 und ergibt 60. Die Bedeutung der Daten entscheidet, ob diese Ersetzung gerechtfertigt ist.

Vergleiche COALESCE innerhalb und außerhalb einer Funktion. AVG(COALESCE(score, 0)) verändert die Werte, die in den Durchschnitt eingehen. COALESCE(AVG(score), 0) verändert nur ein NULL-Endergebnis; für diese Punktzahlen ergibt es weiterhin 80. Oracles NVL(x, 0) ist eine weitere Form mit zwei Argumenten, um NULL zu ersetzen.

Unterscheide keine Zeilen von keinen erfassten Werten

Bei WHERE region = 'South' bleiben keine Bestellungen übrig. Eine Aggregatabfrage ohne GROUP BY gibt dennoch eine Zeile zurück: COUNT(*) ist null, während SUM(amount), AVG(amount), MIN(amount) und MAX(amount) NULL sind. Um eine leere Summe als null anzuzeigen, verwende COALESCE(SUM(amount), 0). SQLite bietet auch TOTAL(amount) an, das bei leerer Eingabemenge 0,0 zurückgibt.

Betrachte nun die vier Bestellungen, deren Rabatt NULL ist. Es gibt Zeilen, aber keine erfassten Rabattwerte: COUNT(*) ist vier, COUNT(discount) ist null und SUM(discount) ist NULL. Null erfasste Werte und vier fehlende Werte sind unterschiedliche Beobachtungen.

Prüfe Ausdrücke, bevor sie in SUM eingehen

Rechnen mit NULL ergibt NULL. In SUM(amount - discount) tragen die vier Bestellungen ohne erfassten Rabatt überhaupt keinen Wert bei. Nur die Zeilen mit bekanntem Rabatt tragen bei: 110, 40, 60 und 135, zusammen 345.

Wenn ein fehlender Rabatt bedeutet, dass kein Rabatt gewährt wurde, schreibe SUM(amount - COALESCE(discount, 0)). Dann trägt jede Bestellung bei; der Gesamtbetrag 780 abzüglich der erfassten Rabatte 30 ergibt 750. Ein COALESCE um die gesamte Summe würde die ausgelassenen Bestellungen nicht zurückbringen, weil 345 bereits nicht NULL ist.

Um fehlende Werte zu finden, verwende IS NULL oder IS NOT NULL. WHERE discount IS NULL findet vier Bestellungen. discount = NULL ist niemals wahr und kann sie daher nicht auswählen.

GROUP BY fasst Zeilen mit demselben Gruppierungswert zusammen. Jedes Aggregat wird innerhalb jeder Gruppe getrennt berechnet, und die Ausgabe enthält eine Zeile für jede nach dem Filtern vorhandene Gruppe.

Entscheide, was eine Ergebniszeile bedeutet

„Gesamtumsatz pro Region“ verlangt eine Ausgabezeile pro Region. Schreibe zunächst diesen Satz auf und verwende dann region als Gruppierungsspalte:

SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY region;

Die drei Beträge aus East, 120, 45 und 95, bilden eine Gruppe. Ihre Anzahl ist drei und ihre Summe 260. North hat zwei Bestellungen mit zusammen 350; West hat zwei mit zusammen 140. Elis Bestellung bildet eine Gruppe mit NULL als Region, einer Bestellung und einer Summe von 30. Es gibt vier Ergebniszeilen, nicht acht.

Lies die Abfrage als Abfolge: FROM liefert Bestellungen, ein vorhandenes WHERE entfernt Zeilen, GROUP BY fasst die verbleibenden Zeilen nach Region zusammen und die Aggregate fassen jede Gruppe zusammen. SELECT zeigt ihre Beschriftung und Kennzahlen an. Die Gruppierung verwirft die kleineren Bestellungen innerhalb einer Gruppe nicht; sie tragen alle bei, sofern sie nicht durch einen Zeilenfilter entfernt wurden.

Halte fehlende Kategorien sichtbar

Zeilen mit NULL in der Gruppierungsspalte gehören zu einer NULL-Gruppe. Das ist nützlich: Ein Bericht kann zeigen, wie viel Aktivität keiner erfassten Region zugeordnet ist. Er behandelt nicht jede fehlende Region als eigene Kategorie.

Um eine lesbare Beschriftung anzuzeigen, wähle COALESCE(region, 'No region') AS region_label und behalte GROUP BY region bei. Die Beschriftung verändert den angezeigten Wert. Um diese Zeilen aus den Berechnungen auszuschließen, ergänze WHERE region IS NOT NULL vor GROUP BY. Die resultierenden Summen ergeben zusammen 750, weil Elis Betrag von 30 ausgelassen wurde.

Eine gruppierte Abfrage über eine Eingabemenge ohne Zeilen gibt keine Gruppen zurück. Filtert man die Tabelle beispielsweise auf South und gruppiert dann nach Region, erhält man keine Ergebniszeilen. Das unterscheidet sich von einem Aggregat über die ganze Tabelle ohne GROUP BY, das selbst bei leerer Eingabemenge eine zusammenfassende Zeile erzeugt.

Sortiere die Gruppen ausdrücklich

GROUP BY garantiert keine Ausgabereihenfolge. Um die größten Regionen zuerst aufzulisten, ergänze ORDER BY total DESC. Der Alias total ist in ORDER BY erlaubt; ORDER BY SUM(amount) DESC ergibt dieselbe Sortierung.

Ein Kundenbericht kann die drei größten Summen auswählen:

SELECT customer, SUM(amount) AS total FROM orders GROUP BY customer ORDER BY total DESC, customer LIMIT 3;

Er gibt Chen 350, Ana 165 und Ben 140 zurück. Das zweite Sortierkriterium, customer, sorgt bei gleichen Summen für eine wiederholbare Reihenfolge. LIMIT 3 gibt nur drei Zeilen zurück; es behält nicht alle gleichen Werte am Grenzwert. SQL Server drückt diese Begrenzung mit SELECT TOP 3 aus, während Oracle FETCH FIRST 3 ROWS ONLY unterstützt.

Beim aufsteigenden Sortieren von Kategorienamen setzt SQLite NULL normalerweise an den Anfang und PostgreSQL an das Ende. Gib die gewünschte Sortierung an, wenn die Position wichtig ist.

Prüfe die Gruppierungsspalte

SELECT DISTINCT region FROM orders und SELECT region FROM orders GROUP BY region geben dieselben unterschiedlichen Regionsbezeichnungen einschließlich NULL zurück. Verwende eine Gruppierung, wenn du auch eine Kennzahl für jede Bezeichnung benötigst.

Die Gruppierung nach der eindeutigen order_id ergibt acht Gruppen mit je einer Zeile. Jede Anzahl ist eins, und jede Betragssumme entspricht dem Betrag der jeweiligen Zeile. Für einen regionalen Bericht zeigt dieses Ergebnis, dass die Gruppierungsspalte zu detailliert ist.

Ein gruppierter Bericht muss viele Eingabezeilen in einer Ergebniszeile zusammenfassen. Jeder angezeigte Wert benötigt daher eine klare Bedeutung für die ganze Gruppe. Deshalb schränkt SQL ein, welche Spalten du auswählen kannst.

Beachte die übertragbare Gruppierungsregel

Ein Eintrag in einem gruppierten SELECT sollte eine Gruppierungsspalte, ein aus Gruppierungsspalten gebildeter Ausdruck, ein Aggregat oder eine Konstante sein. Betrachte:

SELECT region, customer, COUNT(*) FROM orders GROUP BY region;

East enthält Ana, Ana und Dara. Die Gruppe hat eine Region und eine Anzahl, aber zwei verschiedene Kundennamen. Die Abfrage legt nicht fest, welchen Kunden eine einzelne Ergebniszeile für East anzeigen soll. PostgreSQL lehnt die nicht gruppierte Spalte customer ab.

Dasselbe Problem tritt ohne GROUP BY auf: SELECT customer, SUM(amount) FROM orders kombiniert eine Summe über die ganze Tabelle mit einem einzelnen Namen. Für die Summe gibt es keinen einzelnen Kundennamen als Beschriftung.

Korrigiere die Abfrage passend zur Frage

Es gibt drei nützliche Korrekturen, jede mit einer anderen Bedeutung:

• Für eine Zeile pro Region entferne customer: SELECT region, COUNT(*) FROM orders GROUP BY region;.
• Für eine Zeile pro Region und Kunde gruppiere nach beiden: SELECT region, customer, COUNT(*) FROM orders GROUP BY region, customer;.
• Für die Anzahl der Kunden pro Region aggregiere die Namen: SELECT region, COUNT(DISTINCT customer) AS customers FROM orders GROUP BY region;.

Die letzte Abfrage meldet zwei Kunden in East und einen in jeder anderen Regionsgruppe. Eine zusätzliche Spalte in GROUP BY kann die Detailebene des Berichts verändern. Wähle die Korrektur daher anhand der Frage und nicht nur anhand der Fehlermeldung.

Eine Gruppierungsspalte darf in SELECT fehlen. SELECT COUNT(*) FROM orders GROUP BY region; ist zulässig und gibt vier Anzahlen zurück: drei, zwei, zwei und eins, ohne garantierte Reihenfolge. Ohne ihre Regionsbezeichnungen sind diese Zahlen schwer zu verwenden.

Wende die Regel über SELECT hinaus an

Ein ORDER BY customer in einer gruppierten Abfrage hat bei einer Gruppierung allein nach Region dasselbe Problem: Welcher Kunde soll die Position von East bestimmen? Auch HAVING-Bedingungen in gruppierten Abfragen müssen eine ganze Gruppe beschreiben. Verwende dort gruppierte Spalten oder Aggregatausdrücke.

Erkenne nachgiebiges Datenbankverhalten

SQLite akzeptiert eine nicht aggregierte Spalte, also eine ausgewählte Spalte, die weder gruppiert noch aggregiert wird. Es nimmt einen Wert aus einer Eingabezeile der Gruppe. Ein scheinbar erfolgreiches Ergebnis wie 'Ana' neben East bedeutet nicht, dass Ana für jede Bestellung in dieser Region steht.

Bei genau einem eingebauten Aggregat MIN oder MAX nimmt SQLite Werte nicht aggregierter Spalten aus einer Zeile mit dem Extremwert. Bei gleichen Extremwerten und mehreren Aggregaten für Extremwerte ist ungewiss, welche Zeile ausgewählt wird. Diese Abkürzung ist datenbankspezifisch. Wenn du eine Bestellung mit einem Extrembetrag suchst, ist das Sortieren der ursprünglichen Zeilen klarer.

Der Standardmodus ONLY_FULL_GROUP_BY von MySQL lehnt nicht gruppierte Werte ab, die nicht durch die Gruppe bestimmt sind. ANY_VALUE(customer) erlaubt ausdrücklich einen beliebigen Wert, findet aber nicht den Kunden, der zu einer gewählten Summe gehört. SQL Server und Oracle lehnen gewöhnliche nicht gruppierte Spalten ebenfalls ab.

PostgreSQL und MySQL erkennen eine Ausnahme für Primärschlüssel: Die Gruppierung nach dem Primärschlüssel einer Tabelle identifiziert eine einzelne Zeile, sodass deren andere Spalten bestimmt sind. SELECT order_id, customer, SUM(amount) FROM orders GROUP BY order_id funktioniert in PostgreSQL. Alle angezeigten gewöhnlichen Spalten in GROUP BY aufzuführen, bleibt der übertragbare Ansatz.

Manche Berichte benötigen eine Kombination von Kategorien oder eine aus jeder Zeile berechnete Kategorie. SQL kann nach mehreren Spalten oder nach einem Ausdruck gruppieren. Entscheidend bleibt, wofür eine Ausgabezeile steht.

Gruppiere nach einer Kombination

GROUP BY region, customer fasst Zeilen nur zusammen, wenn beide Werte übereinstimmen. Führe für die Bestelltabelle aus:

SELECT region, customer, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY region, customer ORDER BY region, customer;

Die Ergebnisse sind East/Ana: zwei Bestellungen, 165; East/Dara: eine, 95; North/Chen: zwei, 350; West/Ben: zwei, 140; und NULL/Eli: eine, 30. Die beiden Ergebnisse für East ergeben zusammen die regionale Summe von 260.

Die Gruppierung nach customer, region bildet dieselben Kombinationen. Die Spaltenreihenfolge in GROUP BY sortiert die Ausgabe nicht. Das separate ORDER BY oben bestimmt die Anzeige, wobei die Standardposition von NULL von der jeweiligen Datenbank abhängt.

Es erscheinen nur Kombinationen, die in der Eingabemenge vorkommen. Es gibt keine Zeile West/Ana mit der Anzahl null. Die Gruppierung fasst vorhandene Zeilen zusammen; sie erzeugt nicht jede mögliche Paarung von Kategorienamen.

Ergänze Details nur bei Bedarf

Eine zusätzliche Spalte teilt eine Gruppe nur dann auf, wenn deren Zeilen in dieser Spalte unterschiedliche Werte enthalten. Die Gruppierung allein nach Kunde ergibt hier bereits fünf Gruppen. Mit Region sind es weiterhin fünf, weil jeder Kunde nur einen Regionswert hat. Ergänzt man order_date in einem regionalen Bericht, entstehen kleinere Gruppen für die einzelnen Daten und die beantwortete Frage ändert sich.

Gruppiere Datumswerte nach Jahr und Monat

Verwende in SQLite strftime('%Y-%m', order_date), um eine Bezeichnung wie '2026-02' zu erzeugen:

SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY strftime('%Y-%m', order_date) ORDER BY month;

Januar hat zwei Bestellungen mit zusammen 200, Februar drei mit zusammen 305 und März drei mit zusammen 275. Ersetze in PostgreSQL für eine DATE-Spalte beide Vorkommen von strftime('%Y-%m', order_date) durch to_char(order_date, 'YYYY-MM').

Eine Gruppierung allein nach der Monatsnummer fasst denselben Monat über mehrere Jahre hinweg zusammen. Januar 2025 und Januar 2026 würden eine Gruppe bilden. Bleibt das Jahr im Gruppierungsausdruck, bleiben die Kalendermonate getrennt.

Die Wiederholung des Ausdrucks in GROUP BY macht die Gruppierung ausdrücklich. SQLite, PostgreSQL und MySQL akzeptieren auch den Ausgabealias, etwa GROUP BY month; SQL Server akzeptiert dort keinen SELECT-Alias derselben Ebene.

Bilde Kategorien mit CASE

Ein CASE-Ausdruck kann jede Bestellung vor der Gruppierung beschriften:

SELECT CASE WHEN amount >= 100 THEN 'large' ELSE 'small' END AS size, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY CASE WHEN amount >= 100 THEN 'large' ELSE 'small' END;

Die Kategorie large enthält 120, 200 und 150: drei Bestellungen mit zusammen 470. Die Kategorie small enthält fünf Bestellungen mit zusammen 310. Der Schwellenwert ist eingeschlossen, sodass ein Betrag von genau 100 zu 'large' gehört. Derselbe CASE-Ausdruck steht in der Anzeige und in der Gruppierung, sodass beide dieselbe Kategoriedefinition verwenden.

HAVING prüft Gruppen, nachdem ihre Aggregate berechnet wurden. Verwende es für eine Anforderung wie „Regionen mit einem Gesamtumsatz über 200“. Die Bedingung beschreibt jede regionale Summe, nicht eine einzelne Bestellung.

Zuerst berechnen, dann Gruppen behalten

SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY region HAVING SUM(amount) > 200;

Vor HAVING lauten die regionalen Summen East 260, North 350, West 140 und NULL 30. Die Bedingung behält East mit drei Bestellungen und North mit zwei. Sie entfernt die beiden anderen Ergebnisgruppen; sie entfernt keine ausgewählten Bestellungen innerhalb von East oder North.

Setze HAVING im geschriebenen SQL nach GROUP BY und vor ORDER BY. Die Sortierung wird dann auf die Gruppen angewendet, die die Bedingung erfüllt haben.

Filtere nach Kennzahlen, die du nicht anzeigst

SELECT region FROM orders GROUP BY region HAVING COUNT(*) >= 2; gibt East, North und West zurück. Die Datenbank kann die Zeilen einer Gruppe zählen, um zu entscheiden, ob sie die Bedingung erfüllt, ohne diese Anzahl anzuzeigen. HAVING und SELECT benötigen keine identischen Aggregatlisten.

Du kannst Gruppenbedingungen verknüpfen. HAVING COUNT(*) >= 2 AND AVG(amount) > 80 behält East und North. East hat drei Bestellungen und einen Durchschnitt von etwa 86,67; North hat zwei und einen Durchschnitt von 175. West hat genügend Bestellungen, aber sein Durchschnitt beträgt nur 70. Beide Prüfungen müssen erfüllt sein, weil sie mit AND verknüpft sind; OR würde das Erfüllen einer der beiden Prüfungen genügen lassen.

Finde wiederholte Werte

Gruppieren und Zählen findet auch Duplikate:

SELECT customer, COUNT(*) AS orders FROM orders GROUP BY customer HAVING COUNT(*) > 1;

Ana, Ben und Chen haben jeweils zwei Bestellungen und erfüllen die Bedingung. Dara und Eli haben jeweils eine und erfüllen sie nicht. Um wiederholte E-Mail-Werte in einer Kundentabelle zu finden, gruppiert dasselbe Muster nach email und behält Anzahlen über eins. Die Anzahl gibt an, wie viele Datensätze diesen Wert teilen.

Verwende den Ausdruck, den die Bedingung benötigt

Wiederhole das Aggregat in HAVING: HAVING SUM(amount) > 200. PostgreSQL und Standard-SQL erlauben den Ausgabealias total in dieser Bedingung auf derselben Ebene nicht, SQLite und MySQL dagegen schon. In einem späteren ORDER BY total DESC kann der Alias verwendet werden.

Ein angezeigter gerundeter Wert und der geprüfte Wert können sich unterscheiden. Der exakte Durchschnitt von East ist 260 geteilt durch drei. Wenn du ROUND(AVG(amount), 2) auswählst, aber HAVING AVG(amount) > 86.67 schreibst, wird East entfernt: Sein ungerundeter Durchschnitt liegt unter 86,67. North bleibt. Die Bedingung verwendet genau den Ausdruck, der in HAVING steht. Nur HAVING ROUND(AVG(amount), 2) ... würde den gerundeten Wert prüfen.

Filtere die einzelne Gesamtgruppe

HAVING kann auch ohne ausdrückliches GROUP BY arbeiten. SELECT COUNT(*) FROM orders HAVING COUNT(*) > 5; behandelt alle acht Bestellungen als eine Gruppe, erfüllt die Bedingung und gibt eine Zeile mit acht zurück. Ersetzt du die Bedingung durch COUNT(*) > 10, erhältst du keine Zeilen, keine Zeile mit null.

PostgreSQL unterstützt dieses Muster ebenso wie SQLite ab Version 3.39.0. In einer älteren SQLite-Installation benötigt eine Abfrage mit HAVING ein ausdrückliches GROUP BY.

Eine Bedingung gehört an die Stelle, an der das Beschriebene existiert. Einzelne Bestellungen existieren vor der Gruppierung. Eine regionale Summe existiert erst, nachdem die Bestellungen gruppiert und addiert wurden.

Verfolge die logische Reihenfolge

SQL wird in der Reihenfolge SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT geschrieben. Um das Ergebnis nachzuvollziehen, folge dieser logischen Reihenfolge:

1. FROM liefert die Zeilen.
2. WHERE behält passende Zeilen.
3. GROUP BY bildet Gruppen, und Aggregate berechnen deren Kennzahlen.
4. HAVING behält passende Gruppen.
5. SELECT erzeugt die Ausgabewerte; DISTINCT entfernt auf Wunsch doppelte Ausgabezeilen.
6. ORDER BY sortiert das Ergebnis, und LIMIT behält die gewünschte Anzahl von Zeilen.

Die Datenbank kann ihre interne Ausführung anders anordnen.

Setze jede Bedingung auf die passende Ebene

WHERE SUM(amount) > 200 schlägt fehl, weil die Summe beim Filtern der Zeilen noch nicht existiert. Eine Zeilenbedingung wie region = 'East' kann vor der Gruppierung entschieden werden und gehört in WHERE.

Gehe beide Filter durch

SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM orders WHERE amount >= 60 GROUP BY region HAVING SUM(amount) > 200;

Entferne zuerst die Bestellungen über 45 und 30. East enthält nun 120 und 95, North enthält 200 und 150 und West enthält 80 und 60. Berechne danach die Summen 215, 350 und 140. Behalte zuletzt Summen über 200. Die Ausgabe ist East mit zwei Bestellungen und 215 sowie North mit zwei und 350. Für die NULL-Region bleiben keine Zeilen übrig, sodass sie keine Gruppe bildet.

Verändere beim Verschieben eines Filters nicht die Frage

„Berechne für jede Region den Durchschnitt nur für Bestellungen ab 60“ verwendet WHERE amount >= 60. Der Durchschnitt von East beträgt aus 120 und 95 nun 107,5.

HAVING MIN(amount) >= 60 fragt nach Regionen, in denen jeder Betrag ohne NULL den Schwellenwert erreicht. East wird entfernt, weil sein Minimum 45 ist; North und West bleiben mit ihren ursprünglichen Bestellungen erhalten. Das Verschieben der Bedingung hat die Bedeutung verändert: Statt einzelne Bestellungen auszuwählen, werden ganze Regionen angenommen oder abgelehnt.

Für diesen regionalen Bericht ergibt region <> 'West' in WHERE oder HAVING dasselbe Ergebnis: East und North bleiben, und auch die NULL-Gruppe erfüllt den Vergleich nicht. WHERE formuliert die Zeileneinschränkung direkt und wendet sie vor der Gruppierung an. Um fehlende Regionen ebenfalls zu behalten, benötigt die Bedingung ein ausdrückliches OR region IS NULL.

SELECT-Aliase stehen in PostgreSQL in den früheren Klauseln WHERE und HAVING nicht zur Verfügung. SQLite erlaubt Aliase an mehr Stellen, aber das Ausschreiben der Eingabespalte oder des Ausdrucks macht die beabsichtigte Verarbeitungsstufe deutlich.

Beim Teilen zweier ganzzahliger Werte kann der Nachkommateil verloren gehen, bevor du das Ergebnis überhaupt anzeigst. Das ist wichtig, wenn du aus Summen und Anzahlen ein arithmetisches Mittel oder einen Prozentwert berechnest.

Sorge vor der Division für einen Dezimaloperanden

In SQLite und PostgreSQL gibt 7 / 2 3 zurück. Bei ganzzahliger Eingabe gibt SUM(quantity) / COUNT(*) für die Bestelltabelle 2 zurück: Bei 19 Artikeln geteilt durch acht Bestellungen geht der Nachkommateil verloren. PostgreSQLs SUM einer INTEGER-Spalte gibt BIGINT zurück, sodass hier weiterhin ganzzahlig dividiert wird.

Schreibe 1.0 * SUM(quantity) / COUNT(*), um in beiden Datenbank-Engines 2,375 zu erhalten. Die Multiplikation mit 1,0 erzeugt vor der Division einen Dezimaloperanden. SUM(quantity) / COUNT(*) * 1.0 ergibt 2,0, weil die Division den Nachkommateil bereits abgeschnitten hat. Operationen mit demselben Rang werden von links nach rechts ausgewertet.

Für diese Tabelle ergibt AVG(quantity) in SQLite und PostgreSQL direkt 2,375. Die von Hand geschriebene Formel ist wichtig, wenn du einen anderen Nenner oder einen Prozentwert benötigst.

Berechne einen Prozentwert

Drei der acht Bestellungen haben Beträge von mindestens 100. Die Anzahl dieser Bestellungen geteilt durch die Anzahl aller Bestellungen ergibt ihren Anteil. Multipliziere mit 100,0:

SELECT 100.0 * COUNT(CASE WHEN amount >= 100 THEN 1 END) / COUNT(*) AS pct_large FROM orders;

Das Ergebnis ist 37,5. Verwendest du stattdessen die ganze Zahl 100, ergibt sich in SQLite und bei ganzzahliger Division der Anzahlen in PostgreSQL 37. Nachträgliches Runden würde nur ändern, wie 37 angezeigt wird.

Eine Abfrage über die ganze Tabelle kann keine passenden Zeilen finden. NULLIF(COUNT(*), 0) gibt NULL zurück, wenn die Anzahl null ist, sodass 100.0 * COUNT(discount) / NULLIF(COUNT(*), 0) bei leerer Eingabemenge NULL zurückgibt. Ein ungeschützter Nenner von null löst in PostgreSQL einen Fehler aus; SQLite gibt NULL zurück. Ein NULL-Anteil kann klar für „keine Bestellungen zur Auswertung“ stehen.

Prüfe die Datenbank und den Eingabetyp

Verwende in SQL Server AVG(quantity * 1.0) oder wandle die Eingaben vor der Durchschnittsberechnung in DECIMAL um. In PostgreSQL gibt SUM einer BIGINT-Spalte NUMERIC zurück, sodass sich die Division nicht wie bei SUM einer INTEGER-Spalte verhalten muss. MySQL gibt für Summen ganzzahliger Eingaben DECIMAL zurück.

Auch eine explizite Typumwandlung kann den benötigten Dezimaloperanden erzeugen: Verwende CAST(SUM(quantity) AS REAL) in SQLite oder CAST(SUM(quantity) AS NUMERIC) in PostgreSQL. Die Umwandlung in NUMERIC kann in SQLite eine ganze Zahl erhalten, sodass diese Umwandlung allein keine Dezimaldivision sicherstellt.

Unterscheide exakte Dezimalzahlen von Näherungswerten

Gleitkommatypen speichern binäre Näherungswerte. PostgreSQLs NUMERIC und DECIMAL unterstützen exakte Dezimalwerte; Additionen mit Gleitkommazahlen können kleine Abweichungen wie 0,30000000000000004 anzeigen. SQLites NUMERIC-Affinität bietet keine exakte Dezimalspeicherung. Für exakte Geldsummen speichere dort ganzzahlige Centbeträge, addiere sie und teile zur Anzeige durch 100,0.

Runden bestimmt, wie viele Stellen ein Ergebnis zeigt. Runde erst im letzten Schritt, damit die Darstellung die berechnete Kennzahl nicht verändert.

Runde ein Aggregatergebnis

ROUND(x, n) rundet auf n Stellen nach dem Komma. ROUND(x) rundet auf eine ganze Zahl. Zum Beispiel ist ROUND(3.14159, 2) gleich 3,14.

SELECT region, ROUND(AVG(amount), 2) AS avg_amount FROM orders GROUP BY region; ergibt East 86,67, North 175, West 70 und für die NULL-Region 30. SQLite zeigt möglicherweise 175,0 an, während das NUMERIC-Ergebnis von PostgreSQL 175,00 anzeigt. Beide stehen für dieselbe Zahl. Eine Zahl zu runden und eine Textbeschriftung mit fester Breite zu formatieren, sind unterschiedliche Aufgaben.

Runde nach dem Addieren oder Mitteln

Addiere bei drei Gebühren von 0,44 zuerst zu 1,32 und runde dann auf eine Nachkommastelle, um 1,3 zu erhalten. ROUND(SUM(fee), 1) folgt dieser Reihenfolge. SUM(ROUND(fee, 1)) rundet jede Gebühr auf 0,4 und addiert sie dann, was 1,2 ergibt. Das frühe Runden hat die Summe verändert.

Ebenso ergibt ROUND(100 * 1 / 3, 1) in SQLite und PostgreSQL 33,0, weil die ganzzahlige Division bereits 33 erzeugt hat. ROUND(100.0 * 1 / 3, 1) erhält den Nachkommateil und ergibt 33,3. Wähle den Berechnungstyp vor dem Runden.

Gerundete Anteile ergeben zusammen möglicherweise nicht 100 %. Drei gleiche Anteile können jeweils als 33,3 % angezeigt werden und zusammen 99,9 % ergeben. Die zugrunde liegenden Anteile ergeben weiterhin das Ganze. Berechnest du einen beliebigen Anteil neu, um die angezeigte Summe zu erzwingen, änderst du die Bedeutung dieser angezeigten Zahl.

Verwende einen unterstützten Eingabetyp

PostgreSQL unterstützt ROUND(value, n) mit zwei Argumenten für NUMERIC. Wenn temp vom Typ DOUBLE PRECISION ist, schreibe ROUND(CAST(AVG(temp) AS NUMERIC), 2). Der Durchschnitt von 20,5, 21,25 und 19,0 ist 20,25, und die Typumwandlung ermöglicht das Runden mit zwei Argumenten. Bei ganzzahligem amount ist der Durchschnitt in PostgreSQL bereits NUMERIC, sodass keine Typumwandlung nötig ist.

Bei exakten NUMERIC-Werten rundet PostgreSQL Rundungsgrenzfälle von null weg: 2,5 wird zu 3 und -2,5 wird zu -3. SQLite ergibt bei diesen Beispielen ebenfalls 3,0 und -3,0. Das Runden von Gleitkommazahlen in PostgreSQL hängt von der Plattform ab; häufig wird zur nächsten geraden Zahl gerundet. Durch binäre Näherung kann eine Dezimalzahl auch knapp unter einem vorgesehenen Rundungsgrenzfall liegen. Verwende einen bestimmten Gleitkomma-Grenzfall nicht als allgemeine Regel für exakte Dezimalarithmetik.

Beachte zwei weitere Dialektunterschiede

PostgreSQL, MySQL, SQL Server und Oracle verwenden eine negative Anzahl von Dezimalstellen, um links vom Komma zu runden. ROUND(1234.5, -2) ergibt 1200. SQLite behandelt ein negatives zweites Argument als null und ergibt 1235,0. Um in SQLite auf Hunderter zu runden, verwende ROUND(x / 100.0) * 100.

Auch die Umwandlung in eine ganze Zahl ist datenbankspezifisch: SQLite schneidet den Nachkommateil ab, sodass 2,9 zu 2 wird; PostgreSQL rundet den Wert auf 3. Verwende ROUND, wenn gerundet werden soll. PostgreSQLs TRUNC(x, n) schneidet dagegen Stellen ab: TRUNC(2.97, 1) ist 2,9, während das Runden auf eine Nachkommastelle 3,0 ergibt.

Bedingte Aggregation ermöglicht unterschiedliche Beiträge zu verschiedenen Kennzahlen, während dieselben Zeilen insgesamt erhalten bleiben. Ein CASE-Ausdruck entscheidet, was jede Zeile zu einer Anzahl oder Summe beiträgt.

Zähle passende Zeilen

COUNT(CASE WHEN amount >= 100 THEN 1 END) zählt Bestellungen ab 100. Der Ausdruck gibt bei einem Treffer 1 und für andere Zeilen NULL zurück, weil er kein ELSE hat. COUNT überspringt diese NULL-Werte, sodass in der Bestelltabelle drei Treffer bleiben.

SUM(CASE WHEN amount >= 100 THEN 1 ELSE 0 END) zählt Treffer, indem Einsen und Nullen addiert werden. Bei vorhandenen Eingabezeilen ergibt sich dieselbe Anzahl. Für COUNT(CASE WHEN amount >= 100 THEN 1 ELSE 0 END) gilt das nicht: Sowohl 1 als auch 0 sind nicht NULL, sodass alle acht Bestellungen gezählt werden.

Addiere passende Beträge

Gib für eine bedingte Summe den Betrag selbst zurück:

SELECT region, COUNT(*) AS orders, COUNT(CASE WHEN amount >= 100 THEN 1 END) AS large_orders, SUM(CASE WHEN amount >= 100 THEN amount ELSE 0 END) AS large_total FROM orders GROUP BY region;

East hat drei Bestellungen, eine große Bestellung und eine Summe großer Bestellungen von 120. North hat zwei Bestellungen, beide groß, mit zusammen 350. West hat zwei Bestellungen, keine großen Bestellungen und eine Summe großer Bestellungen von null. Die NULL-Regionsgruppe hat eine Bestellung und für beide Kennzahlen zu großen Bestellungen jeweils null.

Die Ausgabe behält West, weil seine Eingabezeilen weiterhin existieren. Ein zusätzliches WHERE amount >= 100 würde die Zeilen von West vor der Gruppierung entfernen, sodass West verschwände. Dieser Filter würde außerdem bewirken, dass COUNT(*) nur große Bestellungen zählt, wodurch der Vergleich mit allen Bestellungen verloren ginge.

Verwende den richtigen Nenner

Berechne innerhalb jeder Region den Prozentsatz großer Bestellungen mit ROUND(100.0 * COUNT(CASE WHEN amount >= 100 THEN 1 END) / COUNT(*), 1) AS pct_large. East ergibt 33,3, North 100,0, West 0,0 und die NULL-Gruppe 0,0. Jeder Nenner ist die Bestellanzahl der jeweiligen Gruppe, nicht die Anzahl von acht für die ganze Tabelle.

Schütze bei einem nicht gruppierten Bericht, der keine Zeilen enthalten kann, den Nenner mit NULLIF(COUNT(*), 0). Eine Zählung bei leerer Eingabemenge ergibt null, aber für den Prozentwert einer leeren Grundgesamtheit gibt es keinen Nenner.

Erstelle mehrere Kategoriespalten

Ein einzelnes Ergebnis kann eine Anzahl pro Region zeigen:

SELECT COUNT(CASE WHEN region = 'East' THEN 1 END) AS east, COUNT(CASE WHEN region = 'West' THEN 1 END) AS west, COUNT(CASE WHEN region = 'North' THEN 1 END) AS north FROM orders;

Die Anzahlen sind drei, zwei und zwei. Elis Bestellung gehört zu keiner dieser Prüfungen auf eine benannte Region. Ergänze COUNT(CASE WHEN region IS NULL THEN 1 END), um die eine Bestellung ohne Region zu zählen. Der Vergleich einer NULL-Region mit einem Namen ergibt keine wahre Bedingung.

Erkenne alternative Schreibweisen

PostgreSQL und SQLite ab Version 3.30.0 unterstützen COUNT(*) FILTER (WHERE amount >= 100). Der Filter gilt für dieses Aggregat, sodass ein benachbartes ungefiltertes COUNT(*) weiterhin alle Bestellungen zählt. MySQL und SQL Server unterstützen diese FILTER-Schreibweise für Aggregate nicht; die CASE-Form funktioniert auf beiden.

SQLite und MySQL erlauben auch SUM(amount >= 100), weil Vergleiche numerische Wahrheitswerte erzeugen. PostgreSQL lehnt SUM für boolesche Werte ab. Verwende die CASE-Form, wenn eine Abfrage auf diesen Datenbank-Engines funktionieren soll.

Eine zusammenfassende Abfrage beginnt mit einer Frage zu einer Grundgesamtheit auf einer bestimmten Detailebene. Übersetze diese Entscheidungen, bevor du SQL schreibst, und prüfe dann, ob die Ausgabe weiterhin die ursprüngliche Frage beantwortet.

Erstelle den Bericht der Reihe nach

Frag dich: „Wie viele Bestellungen wurden in jedem Monat des Jahres 2026 mit mindestens drei Bestellungen aufgegeben, und wie hoch war der durchschnittliche Betrag auf zwei Nachkommastellen?“

1. Die Kennzahlen sind COUNT(*) und AVG(amount).
2. Die Granularität, also die Bedeutung einer Ergebniszeile, ist ein Kalendermonat.
3. Die Zeilenbedingung behält Datumswerte aus 2026.
4. Die Gruppenbedingung verlangt mindestens drei Bestellungen.
5. Die Ausgabe soll nach Monat sortiert und der Durchschnitt für die Anzeige gerundet werden.

In SQLite:

SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders, ROUND(AVG(amount), 2) AS avg_amount FROM orders WHERE order_date >= '2026-01-01' AND order_date < '2027-01-01' GROUP BY strftime('%Y-%m', order_date) HAVING COUNT(*) >= 3 ORDER BY month;

Ersetze für PostgreSQL-Datumswerte den Monatsausdruck an beiden Stellen durch to_char(order_date, 'YYYY-MM'). Der Datumsbereich schließt den Beginn von 2026 ein und den Beginn von 2027 aus.

Januar hat zwei Bestellungen und erfüllt die Gruppenbedingung nicht. Februar hat drei Bestellungen mit zusammen 305 und einem Durchschnitt von 101,67. März hat drei mit zusammen 275 und einem Durchschnitt von 91,67. Auf die verbleibenden Gruppen entfallen sechs Bestellungen, nicht acht, weil HAVING den Januar entfernt hat.

Prüfe, bevor du Gruppen herausfilterst

Führe den Bericht zuerst ohne HAVING aus. Die Anzahlen aller Gruppen sollten zusammen der Zeilenanzahl unter demselben WHERE-Filter entsprechen und die Summen zusammen der nicht gruppierten Summe. Hier ergeben diese Prüfungen acht und 780. Vergleiche die Summen der beibehaltenen Gruppen nicht mit der gesamten Eingabemenge, nachdem Gruppen ausgeschlossen wurden.

Suche nach einer NULL-Gruppe, prüfe die Reihenfolge der Ergebnisse und berechne eine Gruppe nach, indem du die Rohtabelle filterst. Für East sollte WHERE region = 'East' drei Bestellungen mit zusammen 260 ergeben. Eine Abweichung kann eine zusätzliche Gruppierungsspalte, einen falsch platzierten Zeilenfilter oder einen Ausdruck aufdecken, der zu NULL wurde.

Unterscheide eine durchschnittliche Bestellung von einem durchschnittlichen Kunden

AVG(amount) beträgt 97,5 pro Bestellung. Die durchschnittlichen Ausgaben pro Kunde beziehen sich auf eine andere Einheit: Die fünf Kundensummen sind 165, 140, 350, 95 und 30. Ihr Durchschnitt ist 156.

Berechne das in zwei Stufen:

SELECT AVG(total) AS avg_customer_total FROM (SELECT customer, SUM(amount) AS total FROM orders GROUP BY customer) AS per_customer;

Die innere Abfrage erzeugt eine Zeile pro Kunde. Die äußere Abfrage bildet den Durchschnitt dieser Zeilen, sodass jeder Kunde einen Beitrag leistet. Sind alle Kunden benannt, ergibt 1.0 * SUM(amount) / COUNT(DISTINCT customer) dieselbe Zahl 156. Bei unterschiedlichen Bestellanzahlen ist die Durchschnittsbildung über Bestellbeträge eine andere Berechnung.

Fasse die Gruppen selbst zusammen

Um Kunden mit mehr als einer Bestellung zu zählen, liste sie zunächst auf und zähle dann ihre Zeilen:

SELECT COUNT(*) FROM (SELECT customer FROM orders GROUP BY customer HAVING COUNT(*) > 1) AS repeat_customers;

Die Antwort ist drei. Die direkte Verschachtelung von Aggregaten wie in MAX(AVG(amount)) auf einer Abfrageebene schlägt in SQLite und PostgreSQL fehl. Um die Region mit dem höchsten Durchschnitt zu finden, sortiere die gruppierten Durchschnitte: ORDER BY AVG(amount) DESC LIMIT 1 gibt North mit 175 zurück. Oracle unterstützt auch verschachtelte Gruppenfunktionen, aber eine separate Abfrageebene macht die beiden Berechnungen ausdrücklich. Prüfe gleiche Werte, wenn ein Bericht nach dem höchsten Ergebnis fragt.