Databasteknik II: Inlämningsuppgift 3 - Frågeoptimering i Mimer
Mål
-
Att förstå vad exekveringsplaner är, och hur de relaterar till SQL-frågor.
-
Att förstå en del av principerna för frågeoptimering.
-
Att få erfarenhet av hur en riktig databashanterare optimerar frågor.
Uppgift
Titta på exekveringsplaner i Mimer,
och om ni har möjlighet gärna också i andra databashanterare som MySQL och PostgreSQL.
I Mimer är kommandot "SET EXPLAIN ON". Även "SET EXECUTE OFF" användbart.
I MySQL finns kommandot "EXPLAIN".
(I Mimer fungerar "SET EXPLAIN ON" och "SET EXECUTE OFF" inte i dbVisualizer,
utan man måste använda Batch SQL.)
Läs i respektive manual om vad förklaringarna betyder.
Experimentera med olika frågor, tabeller och index,
och försök förstå hur databashanteraren optimerar frågorna.
Exempel på frågeställningar som man kan fundera över och experimentera med:
- Tar optimeraren hänsyn till index? Hur kan man se det?
- Tar optimeraren hänsyn till antalet rader i tabellerna?
- Kan man se på exekveringsplanerna om det är en kostnadsbaserad eller en heuristisk optimerare?
- Kan det bli olika exekveringsplaner beroende på vilka konstanter man har i frågan?
I så fall, varför?
- Hur optimeras frågor med and, or och not?
- Hur optimeras frågor med order by?
- Hur används sammansatta index (dvs ett enda index på flera kolumner)?
- Väljer optimeraren ibland att inte gå via ett index, trots att det vore möjligt? I så fall, varför?
Ledtrådar:
- Är det skillnad på hur index används med frågor som innehåller en likhetsjämförelse (=),
en storleksjämförelse (< eller >) respektive en olikhet (<> eller !=)?
- Hur hanteras olika typer av like-frågor, till exempel namn like 'Olle%' och namn like '%Olle'?
- Spelar det någon roll hur man formulerar frågorna?
- Vilka olika join-algoritmer används, och hur väljer optimeraren mellan dem?
- När används temporära tabeller, och varför?
- Finns det någon fråga där optimeraren misslyckas,
dvs genererar en mycket sämre exekveringsplan än den borde kunna?
Och i så fall, kan man hjälpa optimeraren på något sätt med den frågan?
Lästips
Böcker:
-
Thomas Padron-McCarthy och Tore Risch: Databasteknik, andra upplagan, kapitel 26
(kapitel 25 i första upplagan)
-
Ramez Elmasri och Shamkant B. Navathe: Fundamentals of Database Systems, 7th edition,
kapitel 18 och 19
-
Peter Gulutzan, Trudy Pelzer: SQL Performance Tuning, Addison Wesley, 2002.
ISBN 0-201-79169-2.
592 sidor.
Man brukar få lära sig att det inte spelar någon roll hur man formulerar sina
SQL-frågor, för databashanterarens frågeoptimerare räknar ut
det snabbaste sättet att köra frågan innan den kör den. Men
i verkligheten är frågeoptimerare inte perfekta, och den här
boken beskriver hur olika sätt att skriva samma SQL-fråga
kan ge väldigt olika prestanda.
Mimer-servern på basen.oru.se använder fortfaranade Mimer 10.
Det finns nu en ny version av Mimer, Mimer 11, som är den som man antagligen
vill ladda ner och installera på sin egen dator.
Den visar exekveringsplanerna på ett lite annorlunda sätt.
Se https://developer.mimer.com/
för dokumentation om Mimer 11.
Några bra länkar:
Några exempeltabeller
Om man vill använda lite större tabeller i frågorna än vad man förmodligen orkar skapa själv,
så finns några stora tabeller i schemat exempel i databasen dbk på Mimer-servern basen.oru.se
Dessa tabeller skapades med kommandona i filen
skapa-schemat.txt.
Om man vill provköra på sin egen dator behöver man även datafilen:
fyll-tabeller.zip.
Man kan behöva fylla tabellerna först och skapa indexen sen, för annars kan Mimer ge ett fel.
Glöm inte kommandot update statistics sist!
Obs!
Det verkar som att med den nya Mimer-klienten för Windows (med Mimer
10.1) så får man inte se frågeplanerna från den lite äldre
Mimer-servern som jag kör (10.0). Det funkar med Linux-klienten,
och det funkar om man kör mot en lokal databas på Windows.
Om man gör labben på en egen Windows-dator,
är det nog enklast att skapa en lokal databas och skapa tabellerna där,
enligt ovan.
-
Tabellen exempel.personer innehåller 100000 rader (105), och har inga index.
-
Tabellen exempel.kunder innehåller 10000 rader (104), och har index på alla kolumner.
-
Tabellen exempel.personal innehåller också 10000 rader (104), men har index på
id, personalnummer, namn och gatuadress.
** här nedan betyder att kolumnen har ett primärindex.
* betyder att kolumnen har ett sekundärindex.
Ett understruket kolumnnamn betyder att den kolumnen är deklarerad som unik
(antingen med primary key eller med unique).
exempel.personer
id | namn | gatuadress | postnummer | postadress | telefon |
1 | Alvar Juliussson | Ingalillvägen 52B | 39692 | Slottsskogen | 0688-250729 |
2 | Jane Hakonsson | Tovevägen 76 | 17264 | Barsebäckshamn | 0357-8596510 |
... | ... | ... | ... | ... | ... |
100000 | Conny Sverkersson | Volmarvägen 58 | 15455 | Arnäsvall | 0162-704967 |
exempel.kunder
id** | kundnummer* | namn* | gatuadress* | postnummer* | postadress* | telefon* |
1 | 1000000001 | Henrika Götasson | Paulinavägen 22 | 34121 | Sågmyra | 0646-615801 |
2 | 1000000002 | Eleonora Kajsasson | Esaiasvägen 72B | 40197 | Södra Sunderbyn | 0261-8747610 |
... | ... | ... | ... | ... | .... | ... |
10000 | 1000010000 | Terese Sirisson | Rolandvägen 55A | 93493 | Svalsta | 0787-7091312 |
exempel.personal
id** | personalnummer* | namn* | gatuadress* | postnummer | postadress | telefon |
1 | 100001 | Charlotta Elisabetsson | Håkanvägen 15A | 99067 | Kvänum | 0158-894314 |
2 | 100002 | Toini Helgesson | Mariannevägen 15 | 10119 | Tumba | 0823-6060412 |
... | ... | ... | ... | ... | .... | ... |
10000 | 110000 | Sofia Petrasson | Folkevägen 50A | 83595 | Ånge | 0767-316808 |
Enkla sökningar går snabbt i alla tabellerna,
även på oindexerade kolumner i tabellen exempel.personer,
men joinar mellan två oindexerade kolumner kan bli mycket långsamma
om det ingår många rader i båda av joinens operander.
Redovisning
Skriv en inte alltför lång redogörelse om vad ni kom fram till.
Var tydliga, och ha med exempel.
Diskutera gärna med läraren.
Arbeta i grupper om en eller två studenter.
I undantagsfall kan man arbeta i grupper om tre, men fråga läraren först.
Det är tillåtet att samarbeta i större grupper än så,
men varje grupp om 1-3 studenter måste fortfarande redovisa separat,
och det måste också tydligt framgå (i rapporten eller på annat sätt)
vilka som deltog i samarbetet.
Thomas Padron-McCarthy
(thomas.padron-mccarthy@oru.se),
7 april 2021