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



## Mehrweg-Suchbäume

![[Pasted image 20260723142602.png]]

Ein B-Baum ist ein selbstbalancierender, geordneter M+1-Wege-Suchbaum
- Ale Blätter auf selber Ebene
- Max M Schlüssel pro Knoten
- Min Abgerundet M/2 Schlüssel
- Wurzel Min 1 Schlüssel
- Jeder Knoten mit k Schlüsseln hat k+1 Kinder
![[Pasted image 20260723142759.png]]

### Einfügen in B-Baum

![[Pasted image 20260723142832.png]]


### Löschen in B-Baum
![[Pasted image 20260723142925.png]]
![[Pasted image 20260723142935.png]]
![[Pasted image 20260723143936.png]]



### B+ Baum
- Blätter enthalten Schlüssel mit Datensätzen
- Innere Knoten nur Trennschlüssel
- breiter und weniger hoch als B-Baum
- meist genutzter Baum in Praxis

### Mehrdimensionale Indexstrukturen
Mehrere Attribute gleichzeitig filtern

#### Invertierte Liste
Jedes Attribut eigen durchsuchen
Schnittmenge Bilden
![[Pasted image 20260723144321.png]]

#### Bitmap-Indizes
1 Bit pro Datensatz
1 = Wert ist vorhanden
0 = Wert ist nicht vorhanden
![[Pasted image 20260723145130.png]]
Sehr schnelles COUNT!

Nach deletes entstehen Lücken am Ende weil Einträge nachrücken!
Verundung mit Existenz Bitmap