Indekset e InnoDB janë B+trees: pemë të balancuara ku çdo gjethe (leaf) qëndron në të njëjtën thellësi dhe gjethet janë të lidhura për range scans të shpejta. Një kërkim është O(log n) — një grusht leximesh faqesh edhe në tabela të mëdha.
Një composite index i rendit rreshtat sipas , pastaj , pastaj . Mund ta përdorësh vetëm për një të kolonave: , , ose — por vetëm ose , sepse ato kolona s'janë të renditura derisa të jetë i fiksuar.
(a, b, c)abca(a, b)(a, b, c)b(b, c)aCREATE INDEX idx_abc ON events (user_id, status, created_at);
-- E PËRDOR indeksin (leftmost prefix, range te kolona e fundit)
SELECT * FROM events
WHERE user_id = 7 AND status = 'open' AND created_at > '2026-01-01';
-- NUK e përdor: kapërcen kolonën më të majtë
SELECT * FROM events WHERE status = 'open';
Rendit kolonat sipas selektivitetit më të lartë / barazi së pari, kolona range e fundit: sapo të godasësh një range (>, BETWEEN), kolonat pas saj s'mund të përdoren për seeking.
Nëse një indeks përmban çdo kolonë që query lexon, InnoDB përgjigjet vetëm nga indeksi — pa kthim te clustered index. EXPLAIN shfaq 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, pa kërkim te clustered index
Composite dhe covering indexes janë mënyra si e kthen një query të ngadaltë me shumë kushte në një seek të vetëm indeksi. T'i vësh kolonat në rend të gabuar — ose të presësh që një query mbi kolonën e dytë të përdorë indeksin — është arsyeja më e zakonshme pse një indeks që "ekziston" prapëseprapë nuk përdoret.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro