Načrtovanje in optimizacija baz podatkov

Večina počasnih baz podatkov manjka očitni indeks

Ko se aplikacija upočasni, ko raste, vzrok običajno ni strežnik ali pogon baze podatkov. Je nekaj poizvedb, ki skenirajo cele tabele, ker noben indeks ne ustreza načinu iskanja. Poizvedba, ki je s 1.000 vrsticami trajala 20 milisekund, lahko z milijonom traja sekunde, in nihče tega ne opazi, dokler ne opazijo stranke.

Začnemo z dokazi: lastno statistiko baze podatkov o tem, katere poizvedbe se izvajajo najpogosteje in trajajo najdlje. To običajno kaže na kratek seznam popravkov, kot je indeks na stolpcih, ki jih običajni filter uporablja, poizvedba, preoblikovana tako, da se izogne nalaganju celih tabel, ali manjkajoča povezava med tabelami, ki prisili ponavljajoče se iskanja. Vsako poizvedbo izmerimo pred in po, tako da je izboljšava vidna, ne le trjena.

Omejitve ustavijo slabe podatke na vratih

Številne baze podatkov se zanašajo na aplikacijo, da ohrani podatke čiste. Aplikacija preveri, ali je e-pošta edinstvena, ali naročilo pripada resnemu kupcu in ali količina ni negativna. Nato drugo aplikacija, skripta za uvoz ali pohitro ročno popravilo preskočijo te preverbe, v bazi pa se pojavljajo podvojeni in osamljeni zapisi. Poročila se med seboj ne ujemajo in nihče ni prepričan, katera številka je pravilna.

Dobro oblikovana shema samodejno uveljavlja pomembna pravila: omejitve edinstvenosti, tuji ključi, preverjalne omejitve in smiselne privzete vrednosti. Vsak sistem, ki piše v bazo, jih mora upoštevati. Za obstoječi sistem najdemo mesta, kjer so podatki že napak, načrtujemo čiščenje in nato dodamo omejitve, da se težava ne ponovi.

• Omejitve edinstvenosti za polja, ki se ne smejo ponavljati, kot so e-pošta ali številke faktur
• Tuji ključi, ki preprečujejo, da bi zapisi kazali na nekaj, kar ne obstaja
• Preverjalne omejitve za vrednosti, ki morajo ostati v določenem razponu
• Indeksi, izbrani glede na dejanske vzorce poizvedb, ne dodani povsod