Fortgeschrittenes SQL fuer Data-Analyst-Interviews: Unterabfragen, Pivots und Abfrageoptimierung 2026

Die Bewerbungsverfahren fuer Data-Analyst-Positionen haben sich in den vergangenen Jahren grundlegend veraendert. Im Jahr 2026 beschraenken sich technische SQL-Pruefungen laengst nicht mehr auf einfache SELECT-Abfragen und elementare Joins. Unternehmen aus dem Technologiesektor — ob Scale-ups, Datenberatungen oder Grosskonzerne — erwarten von Kandidaten eine fundierte Beherrschung korrelierter Unterabfragen, Pivot-Transformationen und der systematischen Abfrageoptimierung. Diese technischen Faehigkeiten stellen das zentrale Unterscheidungsmerkmal zwischen einem Junior-Profil und einem erfahrenen Datenanalysten dar. Der vorliegende Artikel erlaeutert die fortgeschrittenen SQL-Muster, die in technischen Bewertungen regelmaessig auftreten, und liefert ausfuehrbare Codebeispiele fuer PostgreSQL 17.

Korrelierte Unterabfragen vs. klassische Unterabfragen

Die Unterscheidung zwischen korrelierten und klassischen Unterabfragen gehoert zu den Grundlagen, die in nahezu jeder technischen SQL-Pruefung abgefragt werden. Eine klassische (nicht korrelierte) Unterabfrage wird genau einmal ausgefuehrt und liefert ein Ergebnis, das unabhaengig vom Kontext der aeusseren Abfrage ist. Die Datenbank-Engine berechnet das Ergebnis der Unterabfrage einmalig und verwendet es anschliessend als festen Vergleichswert fuer die Filterung der Zeilen in der Hauptabfrage.

Im folgenden Beispiel berechnet die Unterabfrage den globalen Durchschnitt der Bestellbetraege. Dieser Wert wird ein einziges Mal ermittelt; anschliessend wird jede Zeile der Tabelle orders mit diesem festen Schwellenwert verglichen.

-- regular_subquery_threshold.sql
-- Find all orders above the average order value
SELECT
  order_id,
  customer_id,
  total_amount
FROM orders
WHERE total_amount > (
  -- Executes once, returns a single scalar value
  SELECT AVG(total_amount)
  FROM orders
);

Eine korrelierte Unterabfrage hingegen referenziert eine oder mehrere Spalten der aeusseren Abfrage. Die Engine muss die Unterabfrage daher fuer jede Zeile der aeusseren Ergebnismenge erneut auswerten. Dieses Verhalten hat unmittelbare Auswirkungen auf die Performance, insbesondere bei grossen Tabellen.

Die klassische Interviewfrage zur Veranschaulichung dieses Mechanismus lautet: Welche Mitarbeiter verdienen mehr als der Gehaltsdurchschnitt ihrer eigenen Abteilung?

-- correlated_subquery_department.sql
-- Employees earning above their department average
SELECT
  e.employee_id,
  e.name,
  e.department,
  e.salary
FROM employees e
WHERE e.salary > (
  -- Re-evaluated for each employee's department
  SELECT AVG(e2.salary)
  FROM employees e2
  WHERE e2.department = e.department
);

Diese Abfrage berechnet den Gehaltsdurchschnitt fuer die Abteilung jedes untersuchten Mitarbeiters neu. Bei Tabellen mit mehreren Hunderttausend Zeilen wird der Laufzeitaufwand prohibitiv. Der optimierte Ansatz besteht darin, die Abteilungsdurchschnitte in einem CTE (Common Table Expression) vorzuberechnen und anschliessend einen einfachen Join mit der Haupttabelle durchzufuehren.

-- optimized_with_cte.sql
-- Same result, single pass over the data
WITH dept_avg AS (
  SELECT
    department,
    AVG(salary) AS avg_salary
  FROM employees
  GROUP BY department
)
SELECT
  e.employee_id,
  e.name,
  e.department,
  e.salary
FROM employees e
JOIN dept_avg d ON e.department = d.department
WHERE e.salary > d.avg_salary;

Die CTE-Variante durchlaeuft die Tabelle employees nur ein einziges Mal, um die Durchschnittswerte zu berechnen, und fuehrt danach den Join aus. Der Leistungsgewinn ist auf Produktionsdatenmengen haeufig erheblich. In Interviews stellt die Faehigkeit, zuerst die korrelierte Variante zu schreiben und diese anschliessend eigenstaendig zum CTE umzubauen, einen starken Indikator technischer Reife dar.

Gaengige Unterabfrage-Patterns in Data-Analyst-Interviews

Drei Unterabfrage-Patterns tauchen systematisch in technischen Bewertungen fuer Data-Analyst-Positionen auf: EXISTS fuer Zugehoerigkeitspruefungen, skalare Unterabfragen in SELECT-Klauseln und abgeleitete Tabellen in FROM-Klauseln.

EXISTS vs. IN — Die EXISTS-Klausel bricht die Auswertung ab, sobald eine Uebereinstimmung gefunden wird. Bei grossen Datenmengen bietet diese Short-Circuit-Strategie einen signifikanten Leistungsvorteil gegenueber IN, das zunaechst das gesamte Ergebnis der Unterabfrage materialisiert, bevor der Vergleich erfolgt.

-- exists_vs_in.sql
-- Customers who placed at least one order in 2026 (EXISTS — preferred)
SELECT c.customer_id, c.name
FROM customers c
WHERE EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.customer_id = c.customer_id
    AND o.order_date >= '2026-01-01'
);

-- Equivalent with IN (slower on large datasets)
SELECT customer_id, name
FROM customers
WHERE customer_id IN (
  SELECT customer_id
  FROM orders
  WHERE order_date >= '2026-01-01'
);

Moderne PostgreSQL-Optimierer koennen in bestimmten Faellen einen IN-Ausdruck in einen Semi-Join umschreiben und so den Leistungsunterschied verringern. Dennoch bleibt EXISTS die empfohlene Formulierung, da sie die Absicht des Entwicklers klarer ausdrueckt und Faelle mit NULL-Werten korrekt behandelt.

Skalare Unterabfrage in SELECT — Dieses Pattern ermoeglicht es, eine berechnete Spalte zum Ergebnissatz hinzuzufuegen, ohne einen expliziten JOIN zu benoetigen. Die Unterabfrage gibt fuer jede Zeile der Hauptabfrage einen einzelnen Wert zurueck.

-- scalar_subquery_select.sql
-- Each product with its category's total revenue
SELECT
  p.product_id,
  p.product_name,
  p.category,
  (
    SELECT SUM(oi.quantity * oi.unit_price)
    FROM order_items oi
    JOIN products p2 ON oi.product_id = p2.product_id
    WHERE p2.category = p.category
  ) AS category_total_revenue
FROM products p;

Dieses Pattern eignet sich gut, um einen Ergebnissatz um ein oder zwei aggregierte Spalten zu erweitern. Darueber hinaus ergibt ein CTE in Kombination mit einem JOIN besser lesbaren und in der Regel leistungsfaehigeren Code, da die Aggregationsberechnung nur einmal pro Kategorie durchgefuehrt wird.

Pivot-Abfragen mit bedingter Aggregation

Pivot-Abfragen gehoeren zu den festen Bestandteilen technischer Data-Analyst-Interviews. Das Grundprinzip besteht darin, zeilenweise gespeicherte Daten in ein spaltenorientiertes Format zu transformieren — typischerweise werden Monate, die als Werte in einer Spalte erfasst sind, in separate Spalten wie jan_revenue, feb_revenue umgewandelt. Obwohl einige Datenbanksysteme einen nativen PIVOT-Operator bereitstellen, basiert der portable und in Interviews universell erwartete Ansatz auf CASE-Ausdruecken innerhalb von Aggregationsfunktionen.

Das erste Beispiel zeigt einen monatlichen Umsatz-Pivot pro Produkt. Jeder CASE-Ausdruck isoliert die Zeilen eines bestimmten Monats, waehrend die SUM-Funktion die Betraege aggregiert.

-- pivot_monthly_revenue.sql
-- Monthly revenue pivot: one row per product, one column per month
SELECT
  product_id,
  product_name,
  SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 1
    THEN quantity * unit_price ELSE 0 END) AS jan_revenue,
  SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 2
    THEN quantity * unit_price ELSE 0 END) AS feb_revenue,
  SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 3
    THEN quantity * unit_price ELSE 0 END) AS mar_revenue,
  SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 4
    THEN quantity * unit_price ELSE 0 END) AS apr_revenue,
  -- Repeat for remaining months
  SUM(quantity * unit_price) AS total_revenue
FROM order_items oi
JOIN orders o ON oi.order_id = o.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date >= '2026-01-01'
GROUP BY product_id, product_name
ORDER BY total_revenue DESC;

Dieselbe Technik der bedingten Aggregation laesst sich auf mehrdimensionale Analysen anwenden. Das folgende Beispiel segmentiert die Benutzeraktivitaet nach Geraetetyp und berechnet den prozentualen Anteil mobiler Sitzungen — ein Kennwert, der in produktorientierten Interviews haeufig abgefragt wird.

-- pivot_user_activity.sql
-- User activity: sessions by day of week and device type
SELECT
  user_id,
  COUNT(CASE WHEN device_type = 'mobile' THEN 1 END) AS mobile_sessions,
  COUNT(CASE WHEN device_type = 'desktop' THEN 1 END) AS desktop_sessions,
  COUNT(CASE WHEN device_type = 'tablet' THEN 1 END) AS tablet_sessions,
  ROUND(
    COUNT(CASE WHEN device_type = 'mobile' THEN 1 END) * 100.0 / COUNT(*),
    1
  ) AS mobile_pct
FROM user_sessions
WHERE session_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY user_id
HAVING COUNT(*) >= 5  -- Only users with meaningful activity
ORDER BY mobile_pct DESC;

Die HAVING-Klausel filtert Benutzer mit einer statistisch nicht aussagekraeftigen Anzahl von Sitzungen heraus. Diese Art der Post-Aggregations-Filterung wird in Interviews regelmaessig herangezogen, um das Verstaendnis der Ausfuehrungsreihenfolge der SQL-Klauseln zu ueberpruefen.

Dynamischer Pivot mit CROSSTAB unter PostgreSQL

Wenn die Pivot-Kategorien nicht im Voraus bekannt sind, stellt die PostgreSQL-Erweiterung tablefunc die Funktion CROSSTAB bereit. Dieser Ansatz ist besonders nuetzlich fuer Berichte, deren Dimensionen dynamisch variieren — beispielsweise ein Quartalspivot, bei dem zukuenftige Quartale in den Daten noch nicht vorhanden sind.

-- crosstab_dynamic_pivot.sql
-- Enable the extension (once per database)
CREATE EXTENSION IF NOT EXISTS tablefunc;

-- Revenue by product and quarter using CROSSTAB
SELECT *
FROM crosstab(
  $$
    SELECT
      product_name,
      'Q' || EXTRACT(QUARTER FROM order_date)::TEXT AS quarter,
      SUM(quantity * unit_price) AS revenue
    FROM order_items oi
    JOIN orders o ON oi.order_id = o.order_id
    JOIN products p ON oi.product_id = p.product_id
    WHERE EXTRACT(YEAR FROM o.order_date) = 2026
    GROUP BY product_name, quarter
    ORDER BY product_name, quarter
  $$,
  $$ VALUES ('Q1'), ('Q2'), ('Q3'), ('Q4') $$
) AS pivot_table(
  product_name TEXT,
  q1_revenue NUMERIC,
  q2_revenue NUMERIC,
  q3_revenue NUMERIC,
  q4_revenue NUMERIC
);

Die erste Dollar-Quoted-Unterabfrage liefert die Quelldaten im Format (Zeilenkategorie, Spaltenkategorie, Wert). Die zweite Unterabfrage definiert explizit die erwarteten Spaltenkategorien. Diese Trennung ermoeglicht es dem Planer, fehlende Werte (ein Produkt ohne Verkaeufe im dritten Quartal beispielsweise) automatisch durch NULL-Werte zu ersetzen.

SQL-Abfrageoptimierung: EXPLAIN-Plaene und Leistungsdiagnose

Die Faehigkeit, eine langsame Abfrage systematisch zu diagnostizieren, unterscheidet praxisorientierte Datenanalysten von rein theoretisch versierten Profilen. Der Befehl EXPLAIN ANALYZE ist das zentrale Werkzeug, um nachzuvollziehen, wie der PostgreSQL-Planer eine Abfrage ausfuehrt, und um Engpaesse zu identifizieren.

-- explain_analyze_example.sql
-- Analyze a slow query to identify bottlenecks
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT
  c.customer_id,
  c.name,
  COUNT(o.order_id) AS order_count,
  SUM(o.total_amount) AS lifetime_value
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= '2025-01-01'
GROUP BY c.customer_id, c.name
HAVING SUM(o.total_amount) > 1000
ORDER BY lifetime_value DESC;

Mehrere Indikatoren in der EXPLAIN-Ausgabe verdienen besondere Aufmerksamkeit. Ein Seq Scan (sequenzieller Tabellenscan) auf einer grossen Tabelle signalisiert in der Regel das Fehlen eines geeigneten Index. Der Vergleich zwischen geschaetzten Zeilen (rows) und tatsaechlich verarbeiteten Zeilen (actual rows) offenbart die Genauigkeit der Planer-Statistiken: Eine grosse Abweichung deutet auf veraltete Statistiken hin, die durch ein ANALYZE auf der betreffenden Tabelle aktualisiert werden koennen. Die BUFFERS-Informationen unterscheiden zwischen aus dem Cache gelesenen Seiten (shared hit) und von der Festplatte gelesenen Seiten (shared read) und liefern damit einen direkten Indikator fuer die Effizienz des PostgreSQL-Caches.

Der gewaehlte Join-Typ (Nested Loop, Hash Join oder Merge Join) haengt von der Groesse der Datenmengen und dem Vorhandensein von Indizes ab. Ein Hash Join wird typischerweise fuer grosse Joins ohne Index gewaehlt, waehrend ein Nested Loop mit Index Scan optimal ist, wenn eine Tabelle deutlich kleiner als die andere ist.

Indexierungsstrategien fuer SQL-Optimierung

Die Indexierung stellt den unmittelbarsten Hebel zur Verbesserung der Antwortzeiten von Abfragen dar. Technische Interviews bewerten die Kenntnis verschiedener Indextypen und die Faehigkeit, die geeignete Strategie abhaengig vom Abfragemuster zu waehlen.

Ein einfacher Index auf einer haeufig in WHERE-Klauseln verwendeten Spalte verbessert die Filterung auf dieser Spalte. Ein zusammengesetzter Index deckt mehrere Spalten ab, wobei die Reihenfolge der Spaltendeklaration bestimmt, welche Abfragen davon profitieren koennen: Die Linkes-Praefix-Regel besagt, dass der Index nur dann verwendbar ist, wenn die Abfrage auf den zuerst deklarierten Spalten filtert.

-- indexing_strategies.sql
-- Index on order_date: filters a small percentage of rows
CREATE INDEX idx_orders_date ON orders (order_date);

-- Composite index for queries filtering on both columns
CREATE INDEX idx_orders_customer_date
  ON orders (customer_id, order_date);

-- Covering index: includes columns needed in SELECT
-- Enables Index Only Scan (no table access)
CREATE INDEX idx_orders_covering
  ON orders (customer_id, order_date)
  INCLUDE (total_amount, status);

Der abdeckende Index (Covering Index) mit der INCLUDE-Klausel fuegt den Blaettern des B-Tree zusaetzliche Spalten hinzu, ohne sie in die Suchschluessel aufzunehmen. Diese Technik ermoeglicht einen Index Only Scan — die Abfrage wird vollstaendig aus dem Index beantwortet, ohne auf die zugrunde liegende Tabelle zugreifen zu muessen, wodurch eine ganze Kategorie von E/A-Operationen entfaellt.

Partielle Indizes bieten eine zusaetzliche Optimierung, indem sie nur eine Teilmenge der Tabellenzeilen abdecken. Bei Tabellen, in denen die Mehrheit der Daten archiviert oder inaktiv ist, erzeugt ein partieller Index auf den aktiven Zeilen einen erheblich kleineren und schneller durchsuchbaren Index.

-- partial_index.sql
-- Only index active orders (smaller, faster index)
CREATE INDEX idx_orders_active
  ON orders (customer_id, order_date)
  WHERE status = 'active';

-- Only index recent data for dashboard queries
CREATE INDEX idx_orders_recent
  ON orders (order_date)
  WHERE order_date >= '2026-01-01';

Der PostgreSQL-Planer verwendet einen partiellen Index nur dann, wenn die WHERE-Klausel der Abfrage mit der Bedingung des Index uebereinstimmt. Diese Besonderheit wird in Interviews regelmaessig abgefragt, um das vertiefte Verstaendnis der Index-Funktionsweise zu ueberpruefen.

Gaengige Abfrage-Anti-Patterns und deren Korrekturen

Bestimmte SQL-Schreibmuster, obwohl syntaktisch valide, neutralisieren die Optimierungen der Datenbank-Engine. Diese erkennen und korrigieren zu koennen, gehoert zu den Kompetenzen, die in fortgeschrittenen technischen Interviews bewertet werden.

Das verbreitetste Anti-Pattern ist die Anwendung einer Funktion auf eine indexierte Spalte. Wenn eine Funktion den Spaltenwert vor dem Vergleich transformiert, kann der Planer den bestehenden Index auf dieser Spalte nicht mehr verwenden, da die im Index gespeicherten Werte nicht mehr mit den verglichenen Werten uebereinstimmen.

-- anti_patterns.sql
-- BAD: function on indexed column disables the index
SELECT * FROM orders
WHERE EXTRACT(YEAR FROM order_date) = 2026;

-- GOOD: range comparison uses the index
SELECT * FROM orders
WHERE order_date >= '2026-01-01'
  AND order_date < '2027-01-01';

Die Umformulierung als Bereichsvergleich bewahrt die Indexnutzung und liefert ein funktional identisches Ergebnis. Dieses Refactoring bringt auf grossen Tabellen haeufig einen betraechtlichen Leistungsgewinn.

Das zweite Anti-Pattern betrifft die Verwendung von NOT IN mit Unterabfragen, die NULL-Werte enthalten koennen. Diese Falle ist besonders tueckisch, da die Abfrage fehlerfrei ausgefuehrt wird, aber eine leere Ergebnismenge liefert. In der dreiwertigen SQL-Logik erzeugt jeder Vergleich mit NULL den Wert UNKNOWN, und NOT IN verhaelt sich wie eine Konjunktion von NOT-EQUAL-Bedingungen — ist eine davon UNKNOWN, wird die gesamte Bedingung ebenfalls UNKNOWN.

-- not_in_null_trap.sql
-- BAD: returns empty if any customer_id is NULL in subquery
SELECT * FROM customers
WHERE customer_id NOT IN (
  SELECT customer_id FROM orders
);

-- GOOD: NOT EXISTS handles NULLs correctly
SELECT * FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.customer_id
);

NOT EXISTS behandelt NULL-Werte korrekt, da die Bedingung auf die Existenz einer Uebereinstimmung prueft und nicht auf einen Wertvergleich abstellt. Dieses Pattern ist NOT IN bei Ausschluessen auf Basis von Unterabfragen systematisch vorzuziehen.

Fazit

Die Vorbereitung auf SQL-Interviews fuer Data-Analyst-Positionen im Jahr 2026 erfordert die Beherrschung mehrerer sich ergaenzender Themenbereiche. Die wesentlichen Erkenntnisse lassen sich wie folgt zusammenfassen:

• Korrelierte Unterabfragen werden fuer jede Zeile der aeusseren Ergebnismenge erneut ausgefuehrt — ihre Umwandlung in CTEs oder Fensterfunktionen verbessert die Leistung auf grossen Tabellen erheblich
• EXISTS uebertrifft IN bei Zugehoerigkeitspruefungen, insbesondere wenn die Unterabfrage eine grosse Zeilenanzahl zurueckgibt oder NULL-Werte enthaelt
• Bedingte Aggregation mit CASE ist die universelle und portable Pivot-Technik — ihre Beherrschung ist Voraussetzung, bevor SGBD-spezifische PIVOT-Syntaxen in Betracht kommen
• EXPLAIN ANALYZE offenbart den tatsaechlichen Ausfuehrungsplan der Abfrage; besonderes Augenmerk gilt Seq Scans, der Genauigkeit der Zeilenschaetzungen und der gewaehlten Join-Strategie
• Die Spaltenreihenfolge in zusammengesetzten Indizes muss den Filtermustern der Abfragen entsprechen — die Linkes-Praefix-Regel gilt durchgaengig
• Partielle und abdeckende Indizes reduzieren E/A-Operationen fuer spezifische Abfragemuster, ohne den Overhead eines die gesamte Tabelle umfassenden Index zu verursachen
• Funktionen auf indexierten Spalten, NOT IN mit NULL-Werten und SELECT * in Produktionsabfragen stellen Anti-Patterns dar, die systematisch eliminiert werden sollten