Ne bomo govorili o samem MySQL, ampak o tem zakaj je pomembna optimizacija SQL stavkov, pri kakšnih sistemih je to pomembno in katere so osnovne tehnike optimizacije, tj. vrste in uporabnost “joinov“, uporaba indexov na poljih in unique-ov in nastavitev polj. Dotaknili se bomo tudi replikacij sistemov in izenačevanje obremenitve (load balancing) in nekaj primerov iz oglasnega sistema Bolha.com.

1. Optimizacija MySql-a
● Osnove
● Vrste tabel
● Benchmarking
● Index-i
● Učinkovitost queryev (poizvedb)

2. Osnove MySql-a
➲ Zakaj MySql?
● Enostavna namestitev
● Enostavna uporaba
➲ Replikacija > zanesljivo, eden od serverjev
sigurno dela
● Tudi zaradi performance
➲ my.cnf > default, za velik sistem bm
➲ Benchmarking > v cvs oz. backup
2 razvoj@3zan.si

3. Vrste tabel
3 razvoj@3zan.si

4. Vrste tabel
➲ MyISAM
● 1. file: .MYD - podatkovni file (privzeta velikost
4 GB)
● 2. file: .MYI – index file (32 biten kazalec do
zapisov v bazi)
● Je mogoče, da se ne da brati ali pisati iz tabele?
Odgovor: Da. Pride do bad sectorja, zmanjka
elektrike.
● Ponovna indeksacija tabele
4 razvoj@3zan.si

5. Benchmarking
➲ Igra “kaj če”
➲ Vse lahko vemo pa se vseeno lahko izkaže,
da ni res.
➲ Bistvo je spreminjanje in testiranje
spremenjenega.
➲ Vsekakor mora biti del vsakega
posodabljanja oz. dodajanja novosti.
➲ Testiramo tudi na realnih podatkih.
● Bolha: Na localhostu imam 50 zapisov, na
Bolhi pa recimo 200 – krat toliko.
5 razvoj@3zan.si

6. Primeri - benchmarking
➲ Ena ponovitev določenega query-ja dela
dobro. Kaj pri 100- ali 1000- kratnih
ponovitvah?
➲ Ali bo dodajanje RAM-a res povečalo hitrost
query-ja za 2- ali 3- krat?
➲ Ima res smisel uporabiti ORDER BY v
query-ju? Odgovor: Ne, če ni nujno in se
čas izvedbe query-ja poveča za 100 -krat
➲ Kaj je bolje: uporaba subquery-ja ali dveh
ločenih query-jev?
6 razvoj@3zan.si

7. Index-i 1/4
➲ Včasih delajo čudeže, včasih pa samo
upočasnjujejo insert stavke in porabljajo
prostor na disku
➲ Kaj sploh je index?
Stvarno kazalo ☺
●
Tabela izbranih polj in pripadajočih kazalcev na
●
zapise teh izbranih polj
● Primer: Telefonski imenik
➲ Naredimo index tistega polja po katerem
največkrat iščemo
➲ Hitrost: DESC, ASC
7 razvoj@3zan.si

8. Index-i 2/4
➲ Ne smemo pretiravati z dodajanjem
index-ov:
Zaradi prevelike porabe prostora na disku
●
Upočasni se izvajanje INSERT, UPDATE in
●
DELETE stavkov
● V skrajnih primerih bi potrebovali že tabelo
index-ov tabele indexov☺
➲ Delna index-acija polj
● Za zelo velike baze, da prihranimo na prostoru
● Primer: priimek(4)
8 razvoj@3zan.si

9. Index-i 3/4
➲ Index-acija več polj
● Če imamo v WHERE-u pogosto dve polji skupaj
● Primer: Bolha (datum, active)
● Kljub temu se poizveduje najprej po prvem in
potem po drugem
● Zakaj ne naredimo index-a na vsako polje
posebej?
➲ Unique
● Uporabljamo jih, kadar smo prepričani, da so
vrednosti nekega polja pri vseh zapisih različni
● Primer: telefonska številka
9 razvoj@3zan.si

10. Index – i 4/4
● Kaj delajo?
● Funkcije index-ov
● Pri INSERT, UPDATE stavkih preveri, če je še kakšen
isti zapis
● Vprašanje, ki se poraja: Kaj je razlika med
unique-om in primary key-om?
10 razvoj@3zan.si

11. Izboljšanje performance query-jev
1/3
➲ Prej ali slej pridemo do počasnih query-jev
(benchmarking)
➲ MySQL ima že optimizer
● Poskuša dobiti odgovore:
● Izbira indeksa s katerim bi najhitreje našli ustrezne
zapise
● Če sodeluje več tabel, izbere kateri indeks je najboljši
● Ugotovi optimalen “join order”
● Ker dela brez testiranja, se moti
● Zato EXPLAIN (ANALYZE TABLE – posodobi
index statistics)
● Primeri
11 razvoj@3zan.si

12. Izboljšanje performance query-jev
2/3
➲ JOIN-i
● Optimizer se sam odloča kateri join bo najprej
bral
● Ni pameten, saj uporablja brute-force
● Poskusi vse kombinacije preden se odloči za
eno (10:1 za testiranje sek.)
➲ Optimizer
● Če imamo ogromno raznovrstno tabelo, moramo
itak pregledati 50% tabele; MySQL ne uporablja
index-ov
● Privzet “cutoff” je 30%
12 razvoj@3zan.si

13. Izboljšanje performance query-jev
3/3
● Če potrebujemo podatke samo iz tabele index-
ov, je pameten
● Pri sortiranju upošteva dva index-a skupaj;
vzame najbolje od obeh (pazljivo)
● Pameten z nemogočimi query-ji
➲ Vrstni red JOIN-ov
● Ponavadi je vseeno (STRAIGHT_JOIN)
➲ Triki
● Dva query-ja je bolje kot eden
● UNION namesto OR
● LEFT_JOIN
13 razvoj@3zan.si

14. Replikacija
➲ Primer: Bolha
➲ Kaj s tem rešimo?
● Porazdelitev podatkov
● Load balancing (Bolha)
● Varnostna kopija (backup) / vzpostavitev stanja
po “sesutju” (recovery)
● Popolna razpoložljivost podatkov
➲ Slabosti
● Delay pri sinhronizaciji
● Slave mora delati isto kot master
14 razvoj@3zan.si

15. Povezave
➲ http://video.google.com/videoplay?docid=2524524540025172110&q=g
oogle+engedu
➲ http://www.java2s.com/Code/SQL/CatalogSQL.htm
15 razvoj@3zan.si