ObsidianVault/SS2026/Datenbanken und Informationssysteme/5. Relationale Anfragebearbeitung/Relationale Anfragebearbeitung.md

!5-RelQuery.pdf

Gleiche SQL-Anfragen können SEHR unterschiedlich schnell ausgewertet werden Optimierung durch DBMS ist KRITISCH!

Anfrageoptimierer

Logische Anfrage zu effizientem physischen Ausführungsplan übersetzen

1. Regelbasiert
2. Kostenbasiert
3. Physisch

Regelbasierte Optimierung

Algebra Ausdruck in einen effizienteren Ausdruck umwandeln

1. Push Selection - früh filtern
2. Push Projection - nur benötigte Attribute
3. Combine Operations - Operationen zusammenfassen, Kreuzprodukte vermeiden
4. Split - \sigma_{A \land B}(R) = \sigma_A(\sigma_B(R)) Konjunktion zerlegen
5. Commute - \sigma_A(\sigma_B(R)) = \sigma_B(\sigma_A(R)) Reihenfolge flexibel
6. Push - \sigma_B(R \times S) = \sigma_B(R) \times S Tupelanzahl reduzieren
7. Push Projection - Projizieren vor Joinen
8. Combine Operations - Select von Kreuzprodukt zu Join zusammenfassen

Heuristischer Algorithmus

!

Regelbasierte Optimierung weiß nicht welcher Plan tatsächlich der schnellste ist!

Kostenbasierte Optimierung

Auswahl guter Join-Reihenfolge + beste konkrete Algorithmen Kosten eines Operators hängen ab von:

1. Größe der Eingabedaten
2. Implementierungsalgorithmus
3. Physischen Parametern Selektivität sel ist der Anteil der Eingabeobjekte der zum Ergebnis gehört. KEIN Kostenmaß - trägt nur dazu bei

Join Reihenfolgen

Binäre Baumstruktur an Joins - Viel zu viele Ergebnisse Left-Deep Baum - Besser aber immer noch zu viele Dynamic Programming - rekursiv Teilpläne betrachten - deutlich besser Greedy - Plan muss nur gut, nicht optimal sein

Physische Optimierung

Selektion:

Full Table Scan <-> Index Scan

Projektion:

Sortieren <-> Hashing

Join:

Nested Loop Join

• Kartesisches Produkt in Reihenfolge
• filter erst beim vergleich
• bR + |R| * bS I/Os Block Nested Loop Join
• S wird nur pro Block von R erneut gescannt
• bR+bR * bS IOPS Sort Merge Join
• Sortieren oder vorsortiert
• Einfach Mergen
• Sehr stark wenn schon sortiert! Hash Join
• Nur für Equi-Joins
• Hashtabelle für kleinere Relation
• gute Hashfunktion notwendig Index Nested Loop Join
• Index nutzen
• bR + |R| * Cost(Index Probe) !