Databasdesign och optimering

De flesta långsamma databaser saknar det uppenbara indexet

När en applikation blir långsammare i takt med att den växer är orsaken oftast inte servern eller databasmotorn. Det är en handfull frågor som skannar hela tabeller eftersom inget index matchar hur de söker. En fråga som tog 20 millisekunder med 1 000 rader kan ta sekunder med en miljon, och ingen märker det förrän kunderna gör det.

Vi utgår från bevis: databasens egna statistik över vilka frågor som körs oftast och tar längst tid. Det pekar vanligtvis på en kort lista av åtgärder, som ett index på de kolumner ett vanligt filter använder, en fråga som skrivs om för att undvika att läsa hela tabeller eller en saknad koppling mellan tabeller som tvingar fram upprepade slagningar. Vi mäter varje fråga före och efter, så förbättringen syns i stället för att bara påstås.

Begränsningar stoppar dålig data vid dörren

Många databaser förlitar sig på applikationen för att hålla data ren. Appen kontrollerar att en e-postadress är unik, att en order tillhör en riktig kund, att en kvantitet inte är negativ. Sedan hoppar en andra app, ett importskript eller en snabb manuell åtgärd över dessa kontroller, och dubbletter och föräldralösa poster smyger sig in. Rapporter börjar gå isär, och ingen är säker på vilken siffra som är rätt.

Ett väl utformat schema upprätthåller de viktiga reglerna självt: unika villkor, främmande nycklar, check-villkor och förnuftiga standardvärden. Allt som skriver till databasen måste följa dem. För ett befintligt system hittar vi var data redan har blivit fel, planerar städningen och lägger sedan till villkoren så att det inte händer igen.

• Unika villkor för sådant som inte får upprepas, som e-postadresser eller fakturanummer
• Främmande nycklar så att poster inte kan peka på något som inte finns
• Kontrollera begränsningar för värden som måste hållas inom intervallet
• Index valda utifrån verkliga frågemönster, inte tillagda överallt