124 lines
3.3 KiB
Markdown
124 lines
3.3 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
|
|
- 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
|
|
|
|
|
|
|
|
|