Databasedesign og optimering

De fleste langsomme databaser mangler det oplagte indeks

Når en applikation bliver langsommere, i takt med at den vokser, er årsagen normalt ikke serveren eller databasemotoren. Det er en håndfuld forespørgsler, der scanner hele tabeller, fordi intet indeks matcher den måde, de søger på. En forespørgsel, der tog 20 millisekunder med 1.000 rækker, kan tage sekunder med en million, og ingen opdager det, før kunderne gør.

Vi starter fra evidens: databasens egne statistikker over, hvilke forespørgsler der kører oftest og tager længst tid. Det peger normalt på en kort liste af rettelser, såsom et indeks på de kolonner, et almindeligt filter bruger, en forespørgsel omskrevet for at undgå at indlæse hele tabeller, eller en manglende forbindelse mellem tabeller, der tvinger gentagne opslag. Vi måler hver forespørgsel før og efter, så forbedringen er synlig i stedet for påstået.

Begrænsninger stopper dårlige data ved døren

Mange databaser er afhængige af applikationen for at holde data rene. Appen kontrollerer, at en e-mail er unik, at en ordre tilhører en rigtig kunde, at en mængde ikke er negativ. Så springer en anden app, et importscript eller en hurtig manuel rettelse disse kontroller over, og dubletter og forældreløse poster sniger sig ind. Rapporter begynder at være uenige, og ingen er sikre på, hvilket tal der er rigtigt.

Et veldesignet schema håndhæver selv de vigtige regler: unikke constraints, foreign keys, check constraints og fornuftige defaults. Alt, hvad der skriver til databasen, skal følge dem. For et eksisterende system finder vi ud af, hvor data allerede er gået galt, planlægger oprydningen og tilføjer derefter constraints, så det ikke sker igen.

• Unikke begrænsninger på ting, der ikke må gentages, som e-mails eller fakturanumre
• Fremmednøgler, så poster ikke kan pege på noget, der ikke findes
• Tjek begrænsninger for værdier, der skal holde sig inden for intervallet
• Indekser valgt ud fra rigtige forespørgselsmønstre, ikke tilføjet overalt