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

54 lines
1.8 KiB
Markdown

![[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
![[Pasted image 20260723134219.png]]
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