Um índice é uma estrutura de dados separada e ordenada (uma B-tree no InnoDB) que permite ao MySQL encontrar linhas sem varrer a tabela inteira. Sem ele, uma busca lê cada linha (um full table scan); com ele, percorre uma árvore em poucos passos.
No InnoDB, a própria tabela é o índice da primary key — um clustered index. As linhas são armazenadas fisicamente em ordem de primary key, então a busca pela primary key aterrissa diretamente na linha completa.
Um índice secundário é uma B-tree separada indexada por outra(s) coluna(s). Seus nós folha armazenam o valor indexado mais a primary key, então usar um índice secundário muitas vezes custa uma segunda busca ("de volta ao clustered index") para buscar o resto da linha.
CREATE TABLE users (
id INT PRIMARY KEY, -- clustered: rows stored in id order
email VARCHAR(255),
city VARCHAR(80)
);
CREATE INDEX idx_city ON users (city); -- secondary B-tree on city
-- Fast: walks idx_city, then primary key for the rest of each row
SELECT * FROM users WHERE city = 'Hanoi';
-- Slow: no index on email -> full table scan
SELECT * FROM users WHERE email = '[email protected]';
Índices aceleram leituras, mas todo INSERT/UPDATE/DELETE também precisa atualizá-los, e eles ocupam disco. Indexe as colunas pelas quais você de fato filtra, faz join ou ordena — não toda coluna.
Índices são a maior alavanca isolada sobre a velocidade de consultas: a diferença entre ler 3 nós de árvore e varrer um milhão de linhas. Saber que o InnoDB faz clustering na primary key também explica por que uma chave curta e monotônica (como AUTO_INCREMENT) mantém os inserts e todo índice secundário enxutos.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar