![[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