GROUP BY und HAVING – wann filtere ich mit WHERE und wann erst nach der Gruppierung?

Du hast völlig recht: Es ist ein Grundprinzip, und wenn du das einmal hast, beantworten sich alle drei Fragen von selbst. Das Prinzip heißt logische Verarbeitungsreihenfolge – und die ist eine andere als die Schreibreihenfolge:

FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

Man schreibt SELECT zuerst, aber die Datenbank wertet es fast zuletzt aus. Damit ist alles erklärt:

1. WHERE läuft vor der Gruppierung und filtert einzelne Zeilen. Zu diesem Zeitpunkt existiert noch keine Gruppe, also kann es auch noch kein COUNT geben – deshalb die Fehlermeldung. HAVING läuft nach der Gruppierung und filtert fertige Gruppen. Faustregel: Bedingung auf einen Einzelwert einer Zeile → WHERE. Bedingung auf ein Ergebnis wie COUNT, SUM oder AVG → HAVING.
2. Warum jede Spalte in GROUP BY muss: Nach dem Gruppieren ist aus vielen Zeilen eine geworden. Fragst du eine Spalte ab, die innerhalb der Gruppe verschiedene Werte hat, gibt es keine sinnvolle Antwort – welchen Namen sollte die Datenbank für eine Abteilung mit acht Mitarbeitern ausgeben? Deshalb gilt: Jede Spalte in SELECT muss entweder in GROUP BY stehen oder in einer Aggregatfunktion. (MySQL/MariaDB waren hier historisch lax und haben irgendeinen Wert geliefert; mit aktivem ONLY_FULL_GROUP_BY verhalten sie sich heute wie die anderen. Verlass dich in der Klausur auf die strenge Regel.)
3. COUNT(*) vs. COUNT(spalte): Das ist kein Zufall, sondern NULL. COUNT(*) zählt Zeilen. COUNT(spalte) zählt nur Zeilen, in denen diese Spalte nicht NULL ist. Wenn drei von zehn Mitarbeitern keine Telefonnummer haben, liefert COUNT(*) zehn und COUNT(telefon) sieben. Dazu kommt COUNT(DISTINCT spalte) für die Anzahl verschiedener Werte.

Deine Abfrage sieht damit ungefähr so aus:

SELECT abteilung, COUNT(*) AS anzahl FROM mitarbeiter WHERE austrittsdatum IS NULL GROUP BY abteilung HAVING COUNT(*) > 5 ORDER BY anzahl DESC

Beachte, dass hier beides vorkommt und das völlig normal ist: WHERE wirft ausgeschiedene Mitarbeiter raus, bevor gezählt wird, HAVING wirft danach die kleinen Abteilungen raus. Ein letzter Merkposten: Der Alias anzahl darf in ORDER BY verwendet werden (das läuft nach SELECT), in WHERE und HAVING dagegen in der Regel nicht – dort musst du den Ausdruck wiederholen.

Tobis Reihenfolge ist der Schlüssel. Ich hänge die Stolperfallen an, die einem nach der Klausur im echten Betrieb begegnen – die kommen aber auch in Aufgaben gern als Teilfrage vor.

1. Der Klassiker: LEFT JOIN plus COUNT(*). Du willst pro Kunde die Anzahl der Bestellungen, auch für Kunden ohne Bestellung. Mit LEFT JOIN bleiben die kundenlosen Zeilen erhalten – aber COUNT(*) zählt trotzdem 1, weil die Zeile ja existiert, nur mit lauter NULL-Werten aus der rechten Tabelle. Richtig ist COUNT(bestellung.bestellID): Das zählt die NULL-Zeile nicht mit und liefert die gewünschte 0. Dieser Fehler ist in Auswertungen extrem verbreitet.

2. NULL bildet eine eigene Gruppe. Gruppierst du nach einer Spalte, in der NULL vorkommt, entsteht eine gemeinsame Gruppe für alle NULL-Werte – obwohl NULL sonst nirgends gleich NULL ist. Praktisch, aber überraschend. Und AVG(spalte) ignoriert NULL-Zeilen komplett: Der Nenner ist dann COUNT(spalte) und nicht COUNT(*). Wenn fehlende Werte als 0 zählen sollen, musst du das mit COALESCE ausdrücklich sagen.

3. Filtere so früh wie möglich. Inhaltlich kannst du eine Zeilenbedingung auch in HAVING unterbringen, wenn die Spalte in GROUP BY steht – sauber ist es trotzdem nicht. WHERE reduziert die Datenmenge, bevor gruppiert wird, und kann Indizes nutzen. HAVING arbeitet auf dem bereits berechneten Zwischenergebnis. Bei großen Tabellen ist das der Unterschied zwischen einer Sekunde und einer Minute.

4. Als Ausblick, falls es im Kurs noch kommt: Wenn du Einzelzeilen und eine Kennzahl gleichzeitig brauchst („jeder Mitarbeiter mit dem Durchschnittsgehalt seiner Abteilung daneben“), ist GROUP BY das falsche Werkzeug, weil es die Zeilen zusammenfasst. Dafür gibt es Fensterfunktionen wie AVG(gehalt) OVER (PARTITION BY abteilung) – sie rechnen dieselbe Kennzahl, behalten aber alle Zeilen. Das ist ein sehr guter Punkt für eine mündliche Prüfung, weil ihn erfahrungsgemäß kaum jemand nennt.

Danke für die Verarbeitungsreihenfolge, die hat bei mir tatsächlich den Knoten gelöst. Ich hänge noch eine Sache an, die mir bei Einsendeaufgaben und Klausuren mehr geholfen hat als jede Syntaxregel: Aufgabentexte lassen sich fast wörtlich in SQL übersetzen.

Ich habe mir dafür eine kleine Übersetzungsliste gemacht:

• „pro Kunde“, „je Abteilung“, „für jede Filiale“ → das ist die Spalte hinter GROUP BY.
• „Anzahl“, „Summe“, „Durchschnitt“, „höchster“ → die Aggregatfunktion im SELECT.
• „nur Aufträge aus 2025“ → Bedingung auf einzelne Zeilen, also WHERE.
• „nur diejenigen Kunden, die mehr als drei Aufträge haben“ → Bedingung auf die fertige Gruppe, also HAVING.
• „absteigend“, „Top 5“ → ORDER BY … DESC und LIMIT.

Wenn beides in einer Aufgabe steht – „Anzahl der Aufträge aus 2025 pro Kunde, aber nur Kunden mit mehr als drei Aufträgen“ –, weiß man sofort, dass das Jahr ins WHERE und die Drei ins HAVING gehört. Genau diese Kombination war bei mir in der Klausur die eigentliche Prüfungsfrage.

Zweiter Tipp: Ich schreibe die Klauseln in der Reihenfolge FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY auf ein Schmierblatt und füge sie dann erst zur fertigen Abfrage zusammen. Klingt umständlich, verhindert aber genau den Fehler, dass man ein COUNT ins WHERE schreibt, weil man mit dem SELECT anfängt.