Alle Tabs der Lerneinheit (Erklärung · Plan-Vergleich · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
Alle Tabs der Lerneinheit (Erklärung · Plan-Vergleich · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Du schreibst eine SQL-Query. Die DB führt sie aus — aber NICHT zwingend in der Reihenfolge, wie du sie geschrieben hast. Der Query Optimizer zerlegt deine Anfrage, baut alternative Pläne, schätzt deren Kosten und wählt den besten aus. Klausur-Pflicht in 8/12 WInf-DB-Klausuren (P2): "Optimiere diesen Anfrage-Baum durch Selektions-Push-Down" oder "Erkläre den Unterschied zwischen logischer und physischer Optimierung".
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Du schreibst eine SQL-Query. Die DB führt sie aus — aber NICHT zwingend in der Reihenfolge, wie du sie geschrieben hast. Der Query Optimizer zerlegt deine Anfrage, baut alternative Pläne, schätzt deren Kosten und wählt den besten aus. Klausur-Pflicht in 8/12 WInf-DB-Klausuren (P2): "Optimiere diesen Anfrage-Baum durch Selektions-Push-Down" oder "Erkläre den Unterschied zwischen logischer und physischer Optimierung".
Logischer Plan: Welche Operatoren (σ, π, ⋈) in welcher Reihenfolge? Physischer Plan: Welcher konkrete Algorithmus pro Operator (Nested Loop Join vs. Hash Join vs. Sort-Merge)?
Beispiel. Logischer Plan einer Query:
π Name
|
σ KursID='DB1'
|
Stud ⋈ Beleg
Physischer Plan dazu könnte sein: "Hash Join auf MatrNr (kleinere Tabelle als Build) → dann Filter auf KursID → dann Projektion auf Name". Oder ganz anders, je nach Statistiken.
Push Selektionen so nah wie möglich an die Eingabe-Tabellen. Je früher du filterst, desto weniger Daten wandern durch die teuren Operatoren (Join, Sort).
Vorher (naiv):
π Name
|
σ KursID='DB1' AND Semester=3
|
Stud × Beleg ← 9 Zeilen (3×3)
Nachher (optimiert):
π Name
|
⋈ MatrNr
/ \
σ Sem=3 σ KursID='DB1'
| |
Stud Beleg
Statt erst das volle Kartesische Produkt (n × m Zeilen) zu bilden und dann zu filtern, filterst du vorher auf beide Tabellen und joinst die kleineren Zwischen-Ergebnisse.
Effekt: bei großen Tabellen kann das den Unterschied zwischen 100ms und 10 Sekunden machen.
Bei mehreren Joins (3+) entscheidet die Reihenfolge über die Performance.
Klassisch: A ⋈ B ⋈ C. Du kannst es als (A ⋈ B) ⋈ C oder A ⋈ (B ⋈ C) auswerten. Wenn A ⋈ B sehr klein ist, beginnst du damit. Wenn B ⋈ C kleiner ist, anders herum.
Optimizer-Heuristik: schätze für jeden Join die Kardinalität (Anzahl Ergebnis-Zeilen) anhand von Statistiken. Wähle die Reihenfolge mit den kleinsten Zwischen-Ergebnissen.
| Algorithmus | Wann gut |
|---|---|
| Nested Loop Join | Eine sehr kleine Tabelle (10–100 Zeilen) als äußere Schleife |
| Hash Join | Equality-Joins auf großen Tabellen, eine passt in den Speicher |
| Sort-Merge Join | Tabellen schon sortiert (z.B. nach Index) oder gleich groß |
Moderne DBs nutzen Statistiken (Tabellen-Größen, Wert-Verteilungen, Index-Selektivität) um Pläne zu bewerten und den günstigsten zu wählen.
Klassiker-Statistiken:
Bei veralteten Statistiken kommt der Optimizer zu falschen Schlüssen → langsame Queries. ANALYZE aktualisiert die Stats.
- Selektions-Push-Down ist die wichtigste Regel — immer prüfen, ob Filter vor Joins ziehen können.
- Logisch vs. physisch auseinanderhalten — Optimizer macht beides.
- EXPLAIN PLAN ist Klausur-Standard-Werkzeug. Lerne die Ausgabe-Struktur deiner DB.
- Hash Join ist meist die schnellste Wahl bei großen Equality-Joins.
- Veraltete Statistiken sind eine häufige Ursache für plötzlich langsame Queries.
1. Selektions-Push-Down geht nicht bei Outer Joins. Bei LEFT OUTER JOIN darfst du WHERE-Bedingungen auf die rechte Seite NICHT push-en, weil das die Outer-Semantik kaputt macht.
2. Indexe lösen alle Probleme. Falsch — auch mit Index kann ein schlecht geschriebener Query langsam sein (z.B. SELECT * mit unnötigen Spalten, fehlende Filter, falscher Join-Typ).
3. Optimizer ist perfekt. Falsch — vor allem bei komplexen Queries (5+ Joins, korrelierte Subqueries) kann der Optimizer schlechte Pläne wählen. Hint-System (z.B. /*+ INDEX(t i) */ in Oracle) kann manuell eingreifen.
4. Logisch vs. physisch verwechseln. Logisch = welche Operatoren, physisch = wie sie ausgeführt werden. Beide sind separate Optimierungs-Phasen.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Wähle eine Query und sieh den naiven Plan (links) vs. den optimierten Plan (rechts). Selektions-Push-Down macht oft 10–100× Performance-Unterschied.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
6 Aufgaben zu logisch/physisch, Push-Down, Join-Algorithmen, Cost-Based Optimization.
Klausurfragen mit Lösungen (6)
Antwort: Selektion möglichst früh ausführen, vor den Joins
Erklärung: Push-Down = nach unten in den Plan-Baum drücken. Selektionen reduzieren die Datenmenge, also möglichst nah an den Eingabe-Tabellen anwenden, bevor teure Joins kommen.
Antwort: Logisch = welche Operatoren in welcher Reihenfolge, physisch = welche Algorithmen
Erklärung: Logisch: σ, π, ⋈ — welche RA-Operatoren in welcher Reihenfolge. Physisch: pro Operator die konkrete Implementierung (Hash Join vs. Nested Loop Join etc.).
Antwort: Hash Join
Erklärung: Hash Join: kleinere Tabelle wird in Hash-Tabelle (im Speicher) gebaut, größere wird scan-weise gegen Hash gemacht. O(n+m) bei genug Speicher. Nested Loop ist O(n*m), Sort-Merge braucht Sortier-Overhead.
Antwort: Falsch
Erklärung: FALSCH. Bei Outer Joins muss man vorsichtig sein: WHERE-Bedingungen auf die rechte Seite (NULL-erweiterte) können die Outer-Semantik kaputt machen. Optimizer prüft das automatisch und führt Push-Down nur dort durch, wo es semantisch erhalten bleibt.
Typ: Wahr/Falsch
Richtige Antworten: Anzahl Zeilen pro Tabelle; Anzahl distinkter Werte pro Spalte; Histogramm der Wert-Verteilung; Selektivität von Indizes
Erklärung: CBO nutzt Mengenstatistiken (Zeilen, distinkte Werte, Histogramme, Index-Selektivität). Tabellenname oder Anzahl Spalten sind irrelevant für die Kosten-Schätzung.
Typ: Multi-Select
Antwort: Alle SELECT * durch SELECT mit allen Spalten ersetzen
Erklärung: SELECT * ist meist sogar langsamer (mehr Daten transferieren), aber semantisch gleich zu SELECT mit allen Spalten. Andere Maßnahmen sind alle sinnvoll: Stats aktualisieren, Plan prüfen, Indizes anlegen.
Klausurfragen mit Lösungen (6)
Antwort: π → σ_{Sem=3}(Stud) ⋈ Beleg
Erklärung: Selektion auf Stud (Sem=3) so früh wie möglich. Statt erst zu joinen und dann zu filtern → vorher filtern, kleineres Ergebnis joinen. Mehr Performance, gleiche Semantik.
Antwort: Die Reihenfolge, die das kleinste Zwischen-Ergebnis erzeugt
Erklärung: Optimizer wählt die Reihenfolge mit dem kleinsten Zwischen-Ergebnis. Das hängt von den Tabellen-Größen und Join-Selektivitäten ab — wird aus Statistiken geschätzt.
Antwort: Wahr
Erklärung: Wahr für die meisten DBs. Statistiken werden meist nicht automatisch beim CREATE INDEX aktualisiert; der Optimizer kennt den neuen Index erst nach ANALYZE oder beim nächsten Vacuum/Maintenance.
Typ: Wahr/Falsch
Richtige Reihenfolge:
Erklärung: Klassische 5 Phasen einer SQL-Engine. Parsen ist Syntax-Check, dann zwei Optimierungs-Phasen, dann Ausführung, dann Liefern. Bei prepared statements wird der Plan gecacht (Phasen 2-3 entfallen beim Wiederverwenden).
Typ: Reihenfolge
Antwort: Alle vier Optionen sind plausibel
Erklärung: Alle plausibel: 1) kein Index → Full Scan; 2) veraltete Stats → falsche Kosten-Schätzung; 3) kleine Tabelle → Full Scan billiger als Index-Lookup. EXPLAIN PLAN zeigt warum.
Lösungen pro Lücke:
Erklärung: Klausur-Pflichtwissen: Push-Down + physische Operator-Wahl sind die zwei Hauptachsen. Logische Reorder + physische Algorithmen.
Typ: Lückentext