SQL Interview Fragen: Die häufigsten Abfrageszenarien mit Lösungen

Welche SQL Interview Fragen kommen am häufigsten vor?

SQL Interview Fragen sind technische Aufgaben, mit denen Unternehmen prüfen, wie sicher Sie Daten filtern, gruppieren, verknüpfen und bewerten und wie Sie über Performance nachdenken. Am häufigsten kommen Summen pro Kunde, Kunden ohne Bestellung, der zweithöchste Wert, die besten N pro Gruppe, Dubletten, laufende Summen und langsame Abfragen vor.

In diesem Beitrag gehe ich diese Szenarien einzeln durch. Zu jedem Szenario erkläre ich zunächst, was die Frage wirklich verlangt. Danach zeige ich eine funktionierende Abfrage und schließlich die Falle, auf die der Interviewer wartet. Wenn Sie SQL gerade erst lernen, ist dieser Text noch zu früh. Lernen Sie deshalb zuerst die Grundbefehle und kommen Sie dann zurück. Beiträge im Stil einer Lernroute finden Sie in der Kategorie Software.

Ich arbeite seit 2012 im Onlinemarketing. Trotzdem liegt SQL jeden Tag auf meinem Tisch, denn Reporting, Kampagnendaten und E-Commerce Bestellungen laufen darüber. Außerdem stelle ich genau diese Fragen, wenn ich Entwickler und Datenanalysten einstelle. Die folgenden Szenarien stammen also aus echten Gesprächen und nicht aus einem Lehrbuch.

Was prüfen Interviewer mit SQL Interview Fragen wirklich?

Der Interviewer will mehr sehen als ein richtiges Ergebnis. Vor allem interessiert ihn, wie Sie über Daten denken. Wenn Sie zum Beispiel lostippen, ohne zu fragen, was eine Zeile der Tabelle darstellt, ist das ein Warnsignal. Man nennt das die Granularität der Tabelle.

Meine eigene Bewertungsliste sieht ungefähr so aus:

• Klärt die Person die Frage und fragt nach Gleichständen, NULL Werten und Zeiträumen?
• Kennt sie die Granularität: Ist eine Zeile eine Bestellung oder eine Bestellposition?
• Baut sie zuerst eine einfache, korrekte Lösung und optimiert erst danach?
• Prüft sie das Ergebnis selbst, etwa über die Zeilenanzahl?
• Kann sie bei Performancefragen über Indizes und Ausführungspläne sprechen?

Kurz gesagt reicht auswendig gelernte Syntax nicht aus. Lautes Denken, klar benannte Annahmen und ein gedanklicher Test mit einer kleinen Beispielmenge bringen oft mehr Punkte als eine perfekte Abfrage, die Sie schweigend tippen.

Welche Beispieltabellen nutzen die Szenarien?

Alle Beispiele beruhen auf einem einfachen E-Commerce Schema. So können Sie sich jede Abfrage auf denselben Daten vorstellen. Die Tabellen lauten:

• customers: id, name, city, created_at.
• orders: id, customer_id, order_date, status, total_amount.
• order_items: order_id, product_id, quantity, unit_price.
• products: id, name, category.
• employees: id, name, department_id, salary, manager_id.

Ich schreibe die Abfragen nah am SQL Standard. Allerdings unterscheiden sich manche Funktionen zwischen PostgreSQL und MySQL. Sagen Sie daher gleich zu Beginn, mit welcher Datenbank Sie arbeiten. Zudem lohnt der Hinweis, dass Datumsfunktionen je nach Dialekt abweichen, denn diese kleine Bemerkung zeigt Sorgfalt.

Noch ein Hinweis: In orders steht eine Zeile für eine Bestellung. In order_items steht eine Zeile dagegen für eine Position. Diese Unterscheidung entscheidet über etwa die Hälfte der folgenden Szenarien.

Wie erklären Sie den Unterschied zwischen WHERE und HAVING?

Diese Frage kommt in fast jedem Gespräch in den ersten fünf Minuten. Die kurze Antwort: WHERE filtert einzelne Zeilen vor der Gruppierung, HAVING filtert Gruppen nach GROUP BY. Deshalb können Sie eine Bedingung mit Aggregatfunktion nicht in WHERE schreiben.

Beispielaufgabe: Listen Sie Kunden mit mehr als drei Bestellungen im Jahr 2025 auf. Eine Lösung: SELECT customer_id, COUNT(*) AS anzahl FROM orders WHERE order_date >= MAKE_DATE(2025, 1, 1) AND order_date < MAKE_DATE(2026, 1, 1) GROUP BY customer_id HAVING COUNT(*) > 3.

Der Datumsfilter steht also in WHERE (MAKE_DATE ist PostgreSQL Syntax, in MySQL schreiben Sie ein Datumsliteral), der Mengenfilter in HAVING. Der Zusatzpunkt, auf den Interviewer achten: Verschieben Sie den Datumsfilter in HAVING, läuft die Abfrage womöglich trotzdem, gruppiert aber unnötige Zeilen. Zudem ist ein halb offener Zeitraum besser als BETWEEN. Bei Spalten mit Uhrzeit verliert BETWEEN sonst still den größten Teil des letzten Tages. Erwähnen Sie das, dann notiert sich Ihr Gegenüber meist etwas.

Wie ermitteln Sie den Bestellwert für jeden Kunden?

Die Frage wirkt einfach, enthält allerdings zwei Fallen. Erstens: Sollen Kunden ohne Bestellung überhaupt erscheinen? Zweitens: Soll ihre Summe NULL oder null anzeigen? Klären Sie das daher, bevor Sie tippen.

Wenn alle Kunden erscheinen sollen, brauchen Sie einen LEFT JOIN: SELECT c.id, c.name, COALESCE(SUM(o.total_amount), 0) AS summe FROM customers c LEFT JOIN orders o ON o.customer_id = c.id GROUP BY c.id, c.name.

COALESCE macht aus NULL eine Null für Kunden ohne Bestellung. Mit einem INNER JOIN würden diese Kunden dagegen still verschwinden. Außerdem ist wichtig, wo Sie einen weiteren Filter platzieren. Angenommen, Sie wollen stornierte Bestellungen ausschließen. Steht diese Bedingung in WHERE, wird Ihr LEFT JOIN faktisch zum INNER JOIN. Der richtige Ort ist also die ON Klausel: LEFT JOIN orders o ON o.customer_id = c.id AND o.status <> 'cancelled'. Wer das erklären kann, versteht Joins wirklich.

Wie finden Sie Kunden, die nie bestellt haben?

Das ist das klassische Anti Join Szenario, und es gibt drei übliche Lösungen. Interviewer fragen oft, ob Sie alle drei kennen und worin sie sich unterscheiden.

1. LEFT JOIN mit IS NULL: SELECT c.* FROM customers c LEFT JOIN orders o ON o.customer_id = c.id WHERE o.id IS NULL.
2. NOT EXISTS: SELECT c.* FROM customers c WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id).
3. NOT IN: SELECT * FROM customers WHERE id NOT IN (SELECT customer_id FROM orders).

Die eigentliche Falle steckt in Variante drei. Liefert die Unterabfrage auch nur einen NULL Wert, gibt NOT IN gar keine Zeile zurück. Denn der Ausdruck "x NOT IN (1, 2, NULL)" ergibt unbekannt, und WHERE verwirft solche Zeilen. Die PostgreSQL Dokumentation zu Vergleichsoperatoren beschreibt diese dreiwertige Logik.

Deshalb bevorzuge ich in der Praxis NOT EXISTS. Es ist sicher gegenüber NULL, und die meisten modernen Datenbanken machen daraus einen effizienten Plan. Wenn Sie das aussprechen, zeigen Sie, dass Sie über auswendig gelernte Antworten hinausgehen.

Wie finden Sie das zweithöchste Gehalt?

Eine Klassikerfrage, denn Ihre Antwort verrät schnell Ihr Niveau. Die erste Idee ist meist eine Unterabfrage: SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees). Sie funktioniert und behandelt Gleichstände korrekt.

Dann erweitert der Interviewer die Aufgabe: Und das N höchste Gehalt? Spätestens jetzt sollten Sie zu einer Fensterfunktion greifen. Eine Lösung: SELECT DISTINCT salary FROM (SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rang FROM employees) t WHERE rang = 2.

Begründen Sie außerdem die Wahl von DENSE_RANK. Teilen sich zwei Personen das höchste Gehalt, springt RANK beim nächsten Wert auf 3, Rang 2 existiert also nicht. ROW_NUMBER macht dagegen willkürlich eine der beiden Personen zur Nummer zwei. DENSE_RANK lässt keine Lücken und beantwortet somit die Frage nach dem zweithöchsten unterschiedlichen Wert richtig. Fragen Sie schließlich, was passieren soll, wenn es keinen zweiten Wert gibt. Leeres Ergebnis oder NULL? Allein diese Rückfrage hebt Sie ab.

Wie holen Sie den Topverdiener jeder Abteilung?

Dieses Muster heißt die besten N pro Gruppe und ist in Gesprächen für mittlere Erfahrungsstufen sehr beliebt. Das Gerüst bleibt immer gleich: Sie teilen mit PARTITION BY auf, sortieren innerhalb jeder Partition und filtern dann außen.

Die Abfrage: WITH sortiert AS (SELECT e.*, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn FROM employees e) SELECT * FROM sortiert WHERE rn = 1.

Das Ergebnis einer Fensterfunktion können Sie nicht direkt in WHERE nutzen, weil WHERE vor den Fensterfunktionen läuft. Deshalb brauchen Sie eine CTE oder eine Unterabfrage. Die Folgefrage dreht sich fast immer um Gleichstände. Verdienen zwei Personen in einer Abteilung gleich viel, sollen dann beide erscheinen? Falls ja, ersetzen Sie ROW_NUMBER durch RANK. Das PostgreSQL Tutorial zu Fensterfunktionen zeigt die Mechanik mit kurzen Beispielen.

Dasselbe Muster löst auch Aufgaben wie die drei meistverkauften Produkte pro Kategorie oder die letzte Bestellung pro Kunde. Sobald das Muster sitzt, beherrschen Sie die ganze Fragenfamilie.

Wie finden und löschen Sie doppelte Datensätze?

Diese Frage hat zwei Schritte, und am zweiten scheitern die meisten. Dubletten zu finden ist einfach: SELECT email, COUNT(*) FROM customers GROUP BY email HAVING COUNT(*) > 1. Damit sehen Sie, welche Adresse mehrfach vorkommt.

Beim Löschen müssen Sie pro Gruppe einen Datensatz behalten, meist den ältesten. Mit einer Fensterfunktion vergeben Sie zunächst ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at, id) für jede Zeile. Danach löschen Sie alle ids mit einer Nummer größer als 1.

Reife Kandidaten zeigen dabei folgende Zeichen:

• Sie führen dieselbe Logik zuerst als SELECT aus und prüfen die Zahl betroffener Zeilen.
• Zudem löschen sie innerhalb einer Transaktion und bestätigen erst nach der Kontrolle.
• Sie gleichen Groß und Kleinschreibung sowie Leerzeichen an, bevor sie Adressen vergleichen.
• Schließlich schlagen sie eine UNIQUE Einschränkung als dauerhafte Lösung vor.

Der letzte Punkt zählt deshalb am meisten. Dubletten zu bereinigen ist eine einmalige Aufgabe. Echte Ingenieursarbeit sorgt dagegen dafür, dass sie nie wiederkommen.

Wie berechnen Sie laufende Summen und gleitende Durchschnitte?

In Rollen mit Reportingbezug kommt diese Frage fast sicher. Etwa so: Zeigen Sie den Umsatz seit Jahresbeginn pro Tag. Zuerst summieren Sie den Umsatz je Tag, dann setzen Sie eine Fensterfunktion darauf.

Die Abfrage: SELECT tag, umsatz, SUM(umsatz) OVER (ORDER BY tag) AS kumuliert FROM (SELECT CAST(order_date AS DATE) AS tag, SUM(total_amount) AS umsatz FROM orders GROUP BY CAST(order_date AS DATE)) d.

Für einen gleitenden Durchschnitt legen Sie den Rahmen ausdrücklich fest: AVG(umsatz) OVER (ORDER BY tag ROWS BETWEEN 6 PRECEDING AND CURRENT ROW). Das ergibt den Mittelwert der letzten sieben Zeilen. Allerdings steckt hier eine feine Falle. Fehlen Tage ohne Umsatz in der Tabelle, sind die letzten sieben Zeilen nicht dasselbe wie die letzten sieben Tage. Erfahrene Kandidaten bemerken das und füllen Lücken mit einer Kalendertabelle.

Ich nutze diese Rechnung ständig in Werbeberichten. Wenn Online Marketing KPIs von Tag zu Tag schwanken, zeigt der gleitende Durchschnitt den echten Trend.

Wie finden Sie Nutzer, die sich an aufeinanderfolgenden Tagen anmelden?

Konkret handelt es sich um das Problem Gaps and Islands, und es trennt in anspruchsvollen Gesprächen die Spreu vom Weizen. Eine typische Aufgabe: Finden Sie Nutzer, die sich an mindestens drei Tagen in Folge angemeldet haben. Zunächst wirkt das schwer, doch es gibt einen bekannten Trick.

Der Trick lautet so: Sie sortieren die Anmeldetage jedes Nutzers und ziehen die Zeilennummer vom Datum ab. An aufeinanderfolgenden Tagen steigen beide Werte um eins, also bleibt die Differenz konstant. Zeilen mit derselben Differenz bilden eine Insel.

1. Entfernen Sie mehrfache Anmeldungen am selben Tag: SELECT DISTINCT user_id, CAST(login_at AS DATE) AS tag.
2. Berechnen Sie ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY tag) je Nutzer.
3. Ziehen Sie die Zeilennummer vom Tag ab und erhalten Sie so einen Gruppenschlüssel.
4. Gruppieren Sie nach user_id und Gruppenschlüssel und filtern Sie mit HAVING COUNT(*) >= 3.

Wer Schritt eins auslässt, zerstört die Serie bei allen, die sich zweimal am selben Tag angemeldet haben. Sprechen Sie diesen Schritt daher laut aus. Die Syntax für Datumsarithmetik unterscheidet sich je nach Datenbank; ein kurzer Hinweis darauf genügt.

Wie berechnen Sie das Wachstum zum Vormonat mit LAG?

Diese Frage prüft, ob Sie auf die vorherige Zeile zugreifen können. Konkret lautet die übliche Aufgabe: Zeigen Sie den Umsatz pro Monat und die prozentuale Veränderung zum Vormonat. Dafür eignet sich LAG ideal.

Zuerst bilden Sie den Monatsumsatz. Dann holt LAG(umsatz) OVER (ORDER BY monat) den Vormonat in dieselbe Zeile. Die Veränderung ergibt sich aus (umsatz - vormonat) * 100.0 / NULLIF(vormonat, 0).

Zwei Details in dieser Formel bringen Punkte. Erstens 100.0 statt 100, denn Datenbanken mit ganzzahliger Division schneiden das Ergebnis sonst ab. Zweitens NULLIF: Ist der Vormonat null, erhalten Sie NULL statt eines Fehlers durch Division durch null. Zudem hat der erste Monat keinen Vorgänger und zeigt daher ebenfalls NULL. Erklären Sie das als erwartetes Verhalten, nicht als Fehler.

Dieselbe Logik steckt in Fragen zur Kundenbindung. Im Marketing lese ich solche Tabellen ständig; wie Sie diese Vergleiche deuten, beschreibe ich im Beitrag Marketing Report richtig lesen.

Wie drehen Sie Zeilen in Spalten um?

Ein Interviewer bittet Sie vielleicht, die Ausgaben jedes Kunden pro Kategorie in einer einzigen Zeile zu zeigen. Kategorien werden also zu Spalten. Nicht jede Datenbank kennt einen PIVOT Befehl, deshalb ist bedingte Aggregation die portable Antwort.

Beispiel: SELECT o.customer_id, SUM(CASE WHEN p.category = 'Elektronik' THEN oi.quantity * oi.unit_price ELSE 0 END) AS elektronik, SUM(CASE WHEN p.category = 'Kleidung' THEN oi.quantity * oi.unit_price ELSE 0 END) AS kleidung FROM orders o JOIN order_items oi ON oi.order_id = o.id JOIN products p ON p.id = oi.product_id GROUP BY o.customer_id.

Entscheidend ist, dass Sie den Betrag aus order_items berechnen. Verknüpfen Sie orders.total_amount mit den Positionen und summieren ihn, wiederholt sich jede Bestellung pro Position, und die Summe bläht sich auf. Diesen Fehler sehe ich in Gesprächen öfter als jeden anderen. Nutzen Sie PostgreSQL, bringt zudem ein Hinweis auf die FILTER Klausel einen Extrapunkt.

Warum sind NULL Werte bei SQL Interview Fragen eine Falle?

NULL bedeutet unbekannt. Es ist weder null noch ein leerer Text. Kurze Fragen zu NULL tauchen unter SQL Interview Fragen häufig auf, weil sie Aufmerksamkeit schnell prüfen. Diese Verhaltensweisen sollten Sie auswendig kennen:

• NULL = NULL liefert nicht wahr; nutzen Sie stattdessen IS NULL.
• COUNT(*) zählt alle Zeilen, COUNT(spalte) überspringt dagegen NULL.
• AVG ignoriert NULL Zeilen im Nenner, daher kann der Wert höher ausfallen als erwartet.
• Ein einziges NULL in einer NOT IN Liste kann das Ergebnis komplett leeren.
• Ob NULL in ORDER BY vorne oder hinten steht, hängt von der Datenbank ab.

Eine typische Frage: Warum liefern COUNT(*) und COUNT(email) unterschiedliche Zahlen? Weil Zeilen mit leerem Feld in der zweiten Zählung fehlen. Gehen Sie einen Schritt weiter und nennen Sie COUNT(*) minus COUNT(email) als Anzahl fehlender Werte. Damit zeigen Sie, dass Sie Daten tatsächlich praktisch nutzen.

Wie analysieren Sie eine langsame Abfrage?

Ab mittlerer Erfahrungsstufe ist diese Frage nahezu sicher. Die richtige Antwort ist eine Methode, keine Vermutung. Ich möchte diese Reihenfolge hören: Ausführungsplan ansehen, Engpass finden, dann die Änderung messen.

EXPLAIN zeigt den Plan. EXPLAIN ANALYZE führt die Abfrage dagegen tatsächlich aus und meldet echte Laufzeiten und Zeilenzahlen. Die PostgreSQL Dokumentation zu EXPLAIN erklärt, warum große Abstände zwischen geschätzten und tatsächlichen Zeilen wichtig sind.

Häufige Ursachen sind:

• Kein Index auf der Spalte, nach der Sie filtern oder verknüpfen.
• Eine indizierte Spalte steckt in einer Funktion, etwa YEAR(order_date) = 2025.
• Breite Zeilen durch ein unnötiges SELECT *.
• Veraltete Statistiken, die den Planer zu einer schlechten Wahl verleiten.

Der zweite Punkt ist die klassische Folgefrage. Umschließt eine Funktion die Spalte, kann die Datenbank einen einfachen Index darauf nicht direkt nutzen. Die Lösung: Schreiben Sie die Bedingung als Datumsbereich. Die Websiteseite solcher Verzögerungen behandle ich im Beitrag wie die Ladezeit SEO beeinflusst.

Welche Fragen zu Indizes sollten Sie erwarten?

Auf die Frage nach langsamen Abfragen folgen Indexfragen. Die häufigste lautet: Was passiert, wenn wir jede Spalte indizieren? Antwort: Lesen kann schneller werden, allerdings muss jedes INSERT, UPDATE und DELETE auch jeden Index aktualisieren. Folglich steigen Schreibkosten und Speicherbedarf.

Die zweite häufige Frage betrifft die Spaltenreihenfolge in einem zusammengesetzten Index. Mit einem Index auf (customer_id, order_date) können Suchen nur nach customer_id ihn nutzen. Eine Suche nur nach order_date kann ihn dagegen meist nicht effizient nutzen. Ein Telefonbuch als Vergleich kommt hier gut an: Ist das Buch nach Nachnamen sortiert, finden Sie niemanden allein über den Vornamen.

Die dritte Frage dreht sich um Selektivität. Ein Index auf eine Statusspalte mit nur zwei Werten hilft allein selten, denn Sie lesen trotzdem einen großen Teil der Zeilen. Die reifste Antwort ist hier schlicht: Ich messe, bevor ich entscheide.

Was sollten Sie über Transaktionen und Isolationsstufen wissen?

Dieses Thema kommt vor allem in Gesprächen für Backend Rollen. Erklären Sie zunächst ACID in einem Satz: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit. Dann folgt das klassische Szenario: Zwei Nutzer kaufen gleichzeitig den letzten Artikel im Lager. Was passiert?

Für die Antwort brauchen Sie Isolationsstufen. Laut PostgreSQL Dokumentation ist Read Committed die Standardstufe. Die MySQL Dokumentation nennt dagegen Repeatable Read als Standard für InnoDB. Wer das weiß, zeigt, dass derselbe Code auf zwei Datenbanken unterschiedlich reagieren kann.

Praktische Antworten auf die Lagerfrage: Sperren Sie die Zeile mit SELECT ... FOR UPDATE, oder schreiben Sie ein bedingtes Update wie UPDATE products SET stock = stock - 1 WHERE id = 5 AND stock > 0 und prüfen Sie dann die Zahl betroffener Zeilen. Das bedingte Update ist die schlankste Lösung, denn es prüft und verringert in einem Schritt. In Projekten der E-Commerce Beratung gehören Lagerabweichungen zu den teuersten Fehlern, die mir begegnen.

Wie gehen Sie an Fragen zu Normalisierung und Schemadesign heran?

Manche Gespräche ersetzen Abfragen durch Design: Modellieren Sie Beiträge, Autoren und Schlagwörter für einen Blog. Der Interviewer prüft dann, ob Sie die Beziehungen richtig anlegen. Beiträge und Schlagwörter stehen in einer n zu m Beziehung, also brauchen Sie eine Zwischentabelle wie post_tags.

Zur Normalisierung sollten Sie lieber ein Praxisbeispiel geben, statt Normalformen aufzusagen. Angenommen, Sie speichern die Stadt des Kunden in jeder Bestellung. Zieht der Kunde um, widersprechen sich alte Bestellungen und neue Datensätze. Das ist eine Änderungsanomalie in konkreter Form.

Starke Kandidaten wissen zudem, dass Normalisierung nicht immer das Ziel ist. In Reportingtabellen speichern Sie Daten manchmal bewusst doppelt, um Lesezugriffe zu beschleunigen. Entscheidend ist, dass Sie diese Wahl begründen. Architekturentscheidungen auf einer anderen Ebene bespreche ich im Beitrag über Micro Frontends.

Welche Technik passt zu welcher der SQL Interview Fragen?

Die folgende Tabelle stammt aus meinen eigenen Gesprächsnotizen. Wenn Sie die Schlüsselformulierung in einer Aufgabe erkennen, finden Sie damit schnell die passende Technik.

Lernen Sie die Tabelle nicht auswendig. Schreiben Sie stattdessen jede Abfrage einmal selbst. Dann ist das Muster im Gespräch sofort da, und Ihr Kopf bleibt frei für Sonderfälle.

Welche Fehler passieren beim Live Coding am häufigsten?

Die meisten Fehler, die ich sehe, entstehen aus Eile und nicht aus fehlendem Wissen. Der Kandidat hört die Aufgabe und tippt sofort los, ohne nach der Granularität zu fragen. Folglich sieht die Abfrage richtig aus, zählt aber falsch.

Diese Fehler begegnen mir am häufigsten:

• Eine Spalte auswählen, die nicht in GROUP BY steht.
• Bestellsummen mit Positionen verknüpfen und die Summe aufblähen.
• Den letzten Tag eines Zeitraums verlieren.
• Fertig melden, ohne das Ergebnis zu prüfen.
• Eine riesige Abfrage anstreben und am Ende etwas Unlesbares bauen.

Zum letzten Punkt rate ich klar: Teilen Sie die Abfrage mit CTEs in Schritte und erklären Sie jeden Schritt. Interviewer ziehen eine lesbare Abfrage einer cleveren, aber verknoteten vor, denn später lesen auch Kollegen diesen Code.

Wie bereiten Sie sich auf SQL Interview Fragen vor?

Bereiten Sie sich nach Szenarien vor, nicht nach Themen. Legen Sie für jedes Szenario der Tabelle eigene Beispieldaten an und lösen Sie es auf mindestens zwei Wegen. Lösen Sie zum Beispiel den Anti Join sowohl mit NOT EXISTS als auch mit LEFT JOIN und vergleichen Sie die Ergebnisse.

Ein praktischer Wochenplan könnte so aussehen:

1. Erster und zweiter Tag: GROUP BY, HAVING, Joins und Anti Joins.
2. Dritter und vierter Tag: Fensterfunktionen, Ranglisten, LAG und laufende Summen.
3. Fünfter Tag: Gaps and Islands sowie Pivotfragen.
4. Sechster Tag: EXPLAIN lesen, Indizes und Transaktionen.
5. Siebter Tag: Probeläufe mit Zeitlimit und lautem Denken.

Der siebte Tag ist der wichtigste. Ohne laute Übung blockieren Sie womöglich bei einer Abfrage, die Sie eigentlich gut kennen. Dieser Plan ist ein Startpunkt aus meiner Praxiserfahrung, keine Garantie; passen Sie ihn also an Ihr Niveau an.

Lohnt sich SQL auch außerhalb der Softwareentwicklung?

Unbedingt. Ich arbeite im Marketing und verbinde trotzdem Werbe, Bestell und Suchdaten mit SQL. Exportieren Sie etwa Daten aus der Google Search Console und gleichen Sie sie mit Bestellungen ab. Dann sehen Sie, welche Seiten wirklich Umsatz bringen.

Deshalb tauchen SQL Fragen auch in Gesprächen für Datenanalysten, Marketinganalysten und Produktmanager auf. Der Schwierigkeitsgrad schwankt zwar. Dennoch bleiben die Szenarien weitgehend gleich: Aggregation, Joins, Ranglisten und Zeitvergleiche.

Erfasst Ihre Website oder Ihr Shop Daten nicht sauber, liefert selbst starkes SQL keine sinnvollen Antworten. Wenn Sie eine messbare Grundlage wollen, sehen Sie sich mein Angebot für Webdesign an oder schreiben Sie mir über die Kontaktseite.