Die Ausführungsreihenfolge einer SQL-Abfrage

Problem

Hier geht es, dort nicht

In der Lektion über Gruppen hat ORDER BY month den Alias aus SELECT benutzt. In der Lektion über HAVING haben wir das ganze SUM(...) wiederholt, und SUM in WHERE hat einen Fehler gegeben. Warum funktioniert ein Alias an einer Stelle und an einer anderen nicht?

Die Antwort liegt in der Reihenfolge, in der die Datenbank die Abfrage liest. Es ist nicht die Reihenfolge, in der du sie schreibst.

Die Idee

In einer Reihenfolge geschrieben, in einer anderen ausgeführt

Du schreibst so:

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

Die Datenbank denkt so:

FROM: woher die Zeilen kommen;
WHERE: welche Zeilen bleiben;
GROUP BY: die Gruppen;
HAVING: welche Gruppen bleiben;
SELECT: was angezeigt wird und wie es heißt;
ORDER BY: die Sortierung;
LIMIT: wie viele Zeilen.

Das ist die logische Ausführungsreihenfolge einer Abfrage. Die drei geschäftigsten Monate, ohne die stornierten Bestellungen:

SQLDatenbank: Shop

SELECT strftime('%Y-%m', ordered_at) AS month, COUNT(*) AS orders
FROM orders
WHERE status <> 'cancelled'
GROUP BY strftime('%Y-%m', ordered_at)
HAVING COUNT(*) >= 5
ORDER BY orders DESC, month
LIMIT 3;

Schritt für Schritt: FROM nimmt die 60 Bestellungen. WHERE entfernt die 7 stornierten, es bleiben 53. GROUP BY teilt sie in 14 Monate. HAVING behält die sechs mit mindestens 5 Bestellungen. SELECT berechnet Monat und Anzahl und benennt sie. ORDER BY sortiert sie, und LIMIT nimmt die ersten drei.

Genauer, für Neugierige

Das ist die Reihenfolge, in der die Abfrage scheinbar läuft. Der echte Plan kann anders sein: Die Datenbank darf einen Index benutzen oder einen Schritt überspringen, solange das Ergebnis dasselbe ist. Mit Abfrageplänen beschäftigen wir uns im Modul über Indizes.

Die Idee

Warum der Alias in ORDER BY funktioniert

Der Alias entsteht in SELECT, in Schritt 5. ORDER BY ist Schritt 6, also existiert der Name schon:

SQLDatenbank: Shop

SELECT order_id, SUM(quantity * unit_price) AS total
FROM order_items
GROUP BY order_id
ORDER BY total DESC
LIMIT 3;

Die drei größten Bestellungen. Das funktioniert in jeder Datenbank. In WHERE, GROUP BY und HAVING existiert der Alias nach der Regel noch nicht, weil sie vor SELECT kommen.

Probier es aus

Die aktivsten Kunden

Zeige die fünf Kunden mit den meisten Bestellungen: customer_id und die Anzahl in einer Spalte namens orders, die meisten zuerst. Bei Gleichstand kommt die kleinere customer_id zuerst.

SQLDatenbank: Shop

Lösung

SELECT customer_id, COUNT(*) AS orders
FROM orders
GROUP BY customer_id
ORDER BY orders DESC, customer_id
LIMIT 5;

Sieh es dir an

Was SQLite verzeiht

Nach der Regel sollte ein Alias in WHERE nicht funktionieren. Die Produkte, die mit 20 % Rabatt unter 1 € kosten:

SQLDatenbank: Shop

SELECT name, price * 0.8 AS sale
FROM products
WHERE sale < 1;

SQLite akzeptiert es. Es akzeptiert einen Alias auch in GROUP BY:

SQLDatenbank: Shop

SELECT strftime('%Y', ordered_at) AS year, COUNT(*)
FROM orders
GROUP BY year;

Andere Datenbanken sind nicht so nachsichtig. PostgreSQL akzeptiert einen Alias in GROUP BY, aber nicht in WHERE: Dort meldet es, dass es die Spalte sale nicht gibt. SQL Server akzeptiert ihn weder in WHERE noch in GROUP BY.

Die Nachsicht von SQLite hat Grenzen. Wenn der Alias genauso heißt wie eine Spalte, nimmt WHERE die Spalte:

SQLDatenbank: Shop

SELECT name, price * 0.8 AS price
FROM products
WHERE price < 1;

Es kommen zwei Produkte heraus, nicht vier: WHERE price < 1 schaut auf den echten Preis, nicht auf den reduzierten. Und ein Alias eines Aggregats in WHERE ist weiterhin „misuse of aggregate“, weil es in Schritt 2 noch keine Gruppen gibt:

SQLDatenbank: Shop

SELECT order_id, SUM(quantity * unit_price) AS total
FROM order_items
WHERE total > 30
GROUP BY order_id;

Eine Abfrage, die überall funktioniert: In WHERE den Ausdruck wiederholen (WHERE price * 0.8 < 1) und Aliase in ORDER BY frei benutzen.

Übung

Der Monatsbericht

Die Inhaberin will einen Bericht für 2026: für jeden Monat, wie viele Bestellungen es gibt (ohne die stornierten) und von wie vielen verschiedenen Kunden. Monate mit weniger als 3 Bestellungen sind ihr zu ruhig, die braucht sie nicht.

Zeige die Spalten month (Jahr-Monat), orders und customers für die Monate 2026 mit mindestens 3 Bestellungen, ohne die stornierten zu zählen, in der Reihenfolge der Monate.

SQLDatenbank: Shop

Lösung

SELECT strftime('%Y-%m', ordered_at) AS month,
       COUNT(*) AS orders,
       COUNT(DISTINCT customer_id) AS customers
FROM orders
WHERE status <> 'cancelled' AND ordered_at >= '2026-01-01'
GROUP BY strftime('%Y-%m', ordered_at)
HAVING COUNT(*) >= 3
ORDER BY month;

Test

Teste dich

1. Mit welchem Teil beginnt die Datenbank, wenn sie die Abfrage ausführt?FROMSELECTWHERE

2. Warum funktioniert ORDER BY total, wenn total ein Alias aus SELECT ist?Es funktioniert nur in SQLiteWeil total eine Spalte der Tabelle istWeil ORDER BY nach SELECT kommt und der Name schon existiert

3. Was stimmt für WHERE sale < 1, wenn sale ein Alias aus SELECT ist?Keine Datenbank akzeptiert esSQLite akzeptiert es, PostgreSQL meldet einen FehlerEs funktioniert überall

4. Die Abfrage hat ORDER BY orders DESC und LIMIT 3. Wann werden die drei Zeilen genommen?Vor HAVINGNach dem Sortieren, ganz am EndeVor dem Sortieren

Die Reihenfolge der Ausführung einer Abfrage

Cookies