InnoDB-indexes zijn B+trees: gebalanceerde bomen waar elke leaf op dezelfde diepte zit en de leaves gekoppeld zijn voor snelle range scans. Een lookup is O(log n) — een handvol page reads, zelfs op enorme tabellen.
Een composite index sorteert rijen op , dan , dan . Je kunt hem alleen gebruiken voor een van de kolommen: , of — maar alleen of , omdat die kolommen niet gesorteerd zijn tot vaststaat.
(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';
Orden kolommen met de meest selectieve / equality-kolommen eerst en de range-kolom als laatste: zodra je een range raakt (>, BETWEEN), kunnen kolommen daarna niet meer gebruikt worden om te seeken.
Als een index elke kolom bevat die de query leest, beantwoordt InnoDB de query alleen vanuit de index — geen tocht terug naar de clustered index. EXPLAIN toont 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- en covering-indexes zijn hoe je een trage query met meerdere voorwaarden omzet in een enkele index seek. De kolomvolgorde verkeerd hebben — of verwachten dat een query op de tweede kolom de index gebruikt — is de meest voorkomende reden waarom een index die "bestaat" toch niet wordt gebruikt.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren