Databasteknik II: Inlämningsuppgift 6 - 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
- Thomas Padron-McCarthy och Tore Risch: Databasteknik, kapitel 25
- Ramez Elmasri och Shamkant B. Navathe: Fundamentals of Database Systems, kapitel 18
- En Mimer-How-To:
Evaluate SQL using Explain
- Mimer SQL 9.2 Technical Description
- Ur Mimer-manualen: Kommandot
SET EXPLAIN
- Ur Mimer-manualen: Kommandot
SET EXECUTE
- Ur Mimer-manualen: Kommandot
UPDATE STATISTICS
- Ur Mimer-manualen: En annan sorts "optimering":
Optimizing Transactions
- 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.
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.
-
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),
15 juni 2010