WeboracleArtikkelen forklarer dekningsindekser for utviklere som tenker i visninger. Den viser hvordan SELECT-listen, WHERE, ORDER BY og LIMIT påvirker indeksbruk, og hvorfor EXPLAIN bør kobles til reelle frontend-behov.
En dekningsindeks er lett å avfeie som et databaseord. Men for en utvikler som bygger visninger, handler den om noe praktisk: Kan databasen svare på siden uten å gjøre mer arbeid enn nødvendig?
En artikkeloversikt trenger kanskje bare tittel, slug, ingress, dato og kategori. En detaljside trenger body, hovedbilde og forfatter. Et kontrollpanel trenger kanskje status, sist endret og eier. Hvis alle disse visningene bruker samme brede spørring, gjør databasen ofte mer arbeid enn nødvendig.
Hva betyr dekningsindeks?
En indeks kan brukes til å finne rader raskere. En dekningsindeks går et steg videre: den inneholder nok kolonner til at databasen kan svare på spørringen ved å lese fra indeksen, uten å hente resten av raden fra tabellen.
I praksis handler dette om samsvar mellom spørringen og indeksen. Kolonner i WHERE, ORDER BY og SELECT må vurderes sammen.
Start med visningen, ikke indeksen
Utviklere som jobber frontend-nært bør starte med visningen. Hva skal kortet faktisk vise? Trenger det hele body-feltet, eller holder det med excerpt? Trenger det alle metadata, eller bare dato og kategori?
En ryddig kortvisning kan for eksempel bruke:
SELECT article_id, slug, title, excerpt, created_at
FROM articles
WHERE category_id = ?
ORDER BY created_at DESC
LIMIT 12;En indeks som støtter category_id og created_at kan hjelpe databasen med filtrering og sortering. Hvis de valgte kolonnene også ligger i indeksen, kan spørringen bli enda billigere.
Ikke velg alle kolonner av gammel vane
SELECT * er praktisk i utvikling, men ofte dårlig i produksjonsvisninger. Det henter mer data enn siden trenger, gjør caching vanskeligere og kan hindre at indekser dekker spørringen.
For innholdssystemer er dette ekstra viktig fordi body-felt kan være store. En oversiktsside bør sjelden hente full artikkeltekst for alle kort.
EXPLAIN knytter teori til virkelighet
MySQL har verktøy for å vise hvordan en spørring planlegges. EXPLAIN gjør det mulig å se hvilke indekser som vurderes og brukes. Det er nyttig når en visning begynner å bli treg, men det bør tolkes sammen med reelle data og faktisk bruksmønster.
Et godt spørsmål er ikke bare «bruker spørringen en indeks?». Det er også «bruker den riktig indeks for denne visningen, med denne sorteringen og denne datamengden?».
For mange indekser er også en kostnad
Indekser gjør lesing raskere, men de må oppdateres når data skrives. Et CMS med mange små oppdateringer bør derfor ikke legge indeks på alt. Hver indeks bør begrunnes med en faktisk spørring eller en viktig constraint.
WEBoracle-vurdering
WEBoracle har flere visninger som kan dra nytte av tydeligere spørringsdesign: forsiden, scriptbiblioteket, artikkeloversikten, kategorifiltre og kontrollpanel-lister. Hver visning bør hente de feltene den faktisk viser, og tunge felt bør holdes unna oversikter når de ikke trengs.
Konklusjon
Dekningsindekser er ikke bare et DBA-tema. De starter i frontend-spørsmålet: hva trenger denne visningen? Når spørringen er smal, sorteringen tydelig og datafeltene bevisste, får databasen bedre forutsetninger for å svare effektivt.