Az InnoDB indexek B+tree-k: kiegyensúlyozott fák, ahol minden levél ugyanabban a mélységben van, és a levelek össze vannak láncolva a gyors tartomány-scanek érdekében. Egy keresés O(log n) — néhány oldal-olvasás még hatalmas táblákon is.
Egy composite index a sorokat szerint, majd , majd szerint rendezi. Csak az oszlopok használhatod: , vagy — de önmagában vagy , mert azok az oszlopok nincsenek rendezve, amíg rögzítve nincs.
(a, b, c)abca(a, b)(a, b, c)b(b, c)aCREATE INDEX idx_abc ON events (user_id, status, created_at);
-- HASZNÁLJA az indexet (leftmost prefix, tartomány az utolsó oszlopon)
SELECT * FROM events
WHERE user_id = 7 AND status = 'open' AND created_at > '2026-01-01';
-- NEM használja: átugorja a leftmost oszlopot
SELECT * FROM events WHERE status = 'open';
Az oszlopokat a legszelektívebb / egyenlőség-először sorrendbe rendezd, a tartomány-oszlopot utoljára: amint tartományt érsz (>, BETWEEN), az utána következő oszlopok nem használhatók keresésre (seek).
Ha egy index minden oszlopot tartalmaz, amit a lekérdezés olvas, az InnoDB kizárólag az indexből válaszol — nincs visszaút a clustered indexhez. Az EXPLAIN Using index-et mutat.
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, nincs clustered-index keresés
A composite és covering indexek segítségével alakítasz egy lassú, több feltételes lekérdezést egyetlen index-seekké. Az oszlopsorrend elrontása — vagy annak elvárása, hogy egy a második oszlopra vonatkozó lekérdezés használja az indexet — a leggyakoribb ok, amiért egy "létező" index mégsem kerül felhasználásra.
IT interjúkérdések gyűjteménye részletes válaszokkal — Juniortól Seniorig.
Adományozás