InnoDB-indekser er B+trees: balanserte trær der hver løvnode ligger på samme dybde og løvnodene er lenket sammen for raske range-skanninger. Et oppslag er O(log n) — en håndfull sidelesninger selv på enorme tabeller.
En composite index sorterer rader etter , deretter , deretter . Du kan bare bruke den for et av kolonnene: , eller — men alene eller , fordi de kolonnene ikke er sortert før er fastsatt.
(a, b, c)abca(a, b)(a, b, c)b(b, c)aCREATE INDEX idx_abc ON events (user_id, status, created_at);
-- USES the index (leftmost prefix, range on the last column)
SELECT * FROM events
WHERE user_id = 7 AND status = 'open' AND created_at > '2026-01-01';
-- Does NOT use it: skips the leftmost column
SELECT * FROM events WHERE status = 'open';
Sorter kolonnene mest-selektive / likhet først, range-kolonnen sist: så snart du treffer en range (>, BETWEEN), kan kolonnene etter den ikke brukes til å søke.
Hvis en indeks inneholder hver kolonne spørringen leser, svarer InnoDB fra indeksen alene — ingen tur tilbake til clustered index. EXPLAIN viser Using index.
CREATE INDEX idx_cover ON events (user_id, status, id);
EXPLAIN SELECT id FROM events WHERE user_id = 7 AND status = 'open';
-- Extra: Using index <- covering, no clustered-index lookup
Composite og covering indexes er måten du gjør en treg spørring med flere betingelser om til et enkelt index seek. Å få kolonnerekkefølgen feil — eller å forvente at en spørring på den andre kolonnen bruker indeksen — er den vanligste grunnen til at en indeks som "finnes" likevel ikke blir brukt.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner