Os índices do InnoDB são B+trees: árvores balanceadas onde toda folha fica na mesma profundidade e as folhas são encadeadas para varreduras de intervalo rápidas. Uma busca é O(log n) — um punhado de leituras de página mesmo em tabelas enormes.
Um índice composto ordena as linhas por , depois , depois . Você só pode usá-lo para um das colunas: , ou — mas sozinha ou , porque essas colunas não estão ordenadas até estar fixo.
(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';
Ordene as colunas mais seletivas / de igualdade primeiro, a coluna de intervalo por último: assim que você atinge um intervalo (>, BETWEEN), as colunas depois dele não podem ser usadas para seek.
Se um índice contém toda coluna que a consulta lê, o InnoDB responde só a partir do índice — sem ida de volta ao clustered index. O EXPLAIN mostra 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
Índices compostos e covering são como você transforma uma consulta lenta com múltiplas condições em um único index seek. Errar a ordem das colunas — ou esperar que uma consulta na segunda coluna use o índice — é a razão mais comum de um índice que "existe" ainda assim não ser usado.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar