Indexes za InnoDB ni B+trees: miti yenye uwiano ambapo kila leaf iko kwenye kina kile kile na leaves zimeunganishwa kwa range scans za haraka. Lookup ni O(log n) — page reads chache hata kwenye majedwali makubwa mno.
Composite index hupanga rows kwa , kisha , kisha . Unaweza kuitumia tu kwa ya columns: , , au — lakini peke yake au , kwa sababu columns hizo hazijapangwa hadi iwe imeamuliwa.
(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';
Panga columns kwa mpangilio wa selective-zaidi / equality-kwanza, column ya range mwisho: mara unapofika kwenye range (>, BETWEEN), columns baada yake haziwezi kutumika kwa kutafuta (seeking).
Ikiwa index ina kila column ambayo query inasoma, InnoDB hujibu kutoka index pekee — bila safari ya kurudi kwenye clustered index. EXPLAIN inaonyesha 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 na covering indexes ndio jinsi unavyogeuza query ya polepole yenye masharti mengi kuwa index seek moja. Kupanga column order vibaya — au kutegemea query kwenye column ya pili itumie index — ndiyo sababu ya kawaida zaidi ya index inayo"kuwepo" bado kutotumika.
Maktaba ya maswali ya mahojiano ya IT yenye majibu ya kina — kutoka Junior hadi Senior.
Changia