Você escreve uma consulta simples, roda no banco de teste e o resultado aparece instantaneamente. Meses depois, com a tabela cheia, a mesma consulta demora vários segundos. Nada no código mudou — mudou apenas o volume de dados. Na maior parte das vezes, a explicação está em uma única palavra: índice.
Índices são um dos assuntos que separam quem apenas escreve SQL de quem entende o que o banco faz com esse SQL. Neste artigo você vai ver o que é um índice, por que ele funciona, o custo que ele cobra e como escolher onde criar cada um.
O que é um índice, na prática
A analogia clássica é a do índice remissivo de um livro. Se você quer encontrar todas as páginas que citam a palavra “fotossíntese”, há dois caminhos: ler o livro inteiro página por página, ou ir ao índice no final, achar a palavra em ordem alfabética e pular direto para as páginas indicadas.
O banco de dados faz exatamente a mesma escolha. Sem índice, ele executa o que se chama de full table scan: percorre todas as linhas da tabela verificando uma a uma se atendem à condição. Com um índice sobre a coluna consultada, ele consulta uma estrutura auxiliar, já ordenada, e vai direto às linhas relevantes.
Essa estrutura auxiliar, na maioria dos bancos relacionais, é uma árvore chamada B-tree (ou sua variante B+tree). O detalhe importante não é o nome, e sim a consequência: buscar em uma árvore balanceada exige um número de comparações que cresce muito devagar conforme a tabela cresce. Dobrar o tamanho da tabela não dobra o tempo da busca indexada — mas dobra, sim, o tempo de uma varredura completa.
Onde os índices realmente fazem diferença
Um índice não acelera “a tabela”. Ele acelera determinadas operações sobre determinadas colunas. Os casos em que o ganho costuma ser mais visível são:
- Filtros no WHERE — colunas usadas com frequência para restringir resultados, como
email,cpfoustatus. - Junções entre tabelas — as chaves estrangeiras usadas nos JOINs. Sem índice do lado “muitos”, cada junção pode virar uma varredura completa.
- Ordenação — um ORDER BY sobre uma coluna já indexada pode dispensar o passo de ordenar os resultados na memória.
- Restrições de unicidade — índices únicos garantem que não existam dois registros com o mesmo valor, e a verificação é rápida justamente por causa da estrutura ordenada.
Note que a chave primária já vem indexada automaticamente na maioria dos bancos. As chaves estrangeiras, não — e é exatamente aí que muitos sistemas ficam lentos sem que ninguém perceba o motivo.
O preço que se paga
Se índices só trouxessem vantagens, o banco criaria um para cada coluna sozinho. Não é o que acontece, porque eles têm três custos concretos.
| Custo | O que significa |
|---|---|
| Espaço em disco | Cada índice é uma estrutura física separada, que ocupa lugar e precisa ser copiada nos backups. |
| Escrita mais lenta | Todo INSERT, UPDATE ou DELETE precisa atualizar também cada índice afetado. |
| Manutenção | Índices se fragmentam com o tempo e as estatísticas precisam estar atualizadas para o otimizador escolher bem. |
Por isso a regra prática é simples de enunciar e difícil de seguir: crie índices para as consultas que realmente existem no seu sistema, não para as que você imagina que talvez existam um dia. Uma tabela com quinze índices costuma ser sinal de que ninguém mediu nada.
Índices compostos e a ordem das colunas
Um índice pode cobrir mais de uma coluna. Nesse caso, a ordem em que você declara as colunas muda tudo. Pense num índice sobre (cidade, bairro): ele funciona como uma lista telefônica ordenada primeiro por cidade e, dentro de cada cidade, por bairro.
- Uma busca por cidade aproveita o índice.
- Uma busca por cidade e bairro aproveita o índice inteiro.
- Uma busca só por bairro normalmente não aproveita — é como procurar todos os “Centro” do país numa lista ordenada por cidade.
Essa característica é chamada de prefixo mais à esquerda. A recomendação usual é colocar primeiro a coluna mais seletiva, isto é, aquela que elimina mais linhas de uma vez.
Quando o banco ignora o índice que você criou
Criar o índice não garante que ele será usado. O otimizador de consultas decide, a cada execução, qual caminho parece mais barato. Alguns motivos comuns para ele decidir varrer a tabela mesmo havendo índice:
- Baixa seletividade — se a coluna tem só dois valores possíveis e você busca o mais comum, ler a tabela toda pode ser mais rápido do que pular de um lado para o outro.
- Função aplicada à coluna — condições como
WHERE UPPER(nome) = 'ANA'costumam anular o índice sobrenome, porque o índice guarda o valor original, não o transformado. - Curinga à esquerda —
LIKE '%silva'não aproveita a ordenação;LIKE 'silva%'aproveita. - Conversão implícita de tipo — comparar uma coluna numérica com um texto pode forçar o banco a converter linha a linha.
- Estatísticas desatualizadas — o otimizador trabalha com estimativas; se elas estiverem erradas, a escolha também estará.
Como investigar em vez de adivinhar
Todo banco relacional oferece um comando para mostrar o plano de execução de uma consulta — normalmente alguma variação de EXPLAIN. Ele revela se houve varredura completa, qual índice foi escolhido e quantas linhas o banco estimou ler.
Um roteiro de trabalho que funciona bem:
- Identifique as consultas mais lentas ou mais frequentes do sistema — não comece pelo palpite.
- Rode o EXPLAIN dessas consultas e observe onde aparecem varreduras completas.
- Crie um índice candidato sobre as colunas do filtro ou da junção.
- Meça de novo, com um volume de dados parecido com o de produção.
- Se não houve ganho real, remova o índice: ele agora é só custo de escrita.
Um resumo para levar
Índices trocam espaço em disco e velocidade de escrita por velocidade de leitura. São indispensáveis em colunas usadas para filtrar, juntar e ordenar, e inúteis (ou prejudiciais) quando criados por precaução. A diferença entre um sistema que escala e um que trava aos poucos raramente está no hardware — está em saber quais consultas o banco realmente executa e dar a ele o caminho certo para chegar aos dados.
Se você quer se aprofundar em modelagem, SQL e otimização de consultas, vale explorar os cursos gratuitos de banco de dados e desenvolvimento back-end disponíveis na Cursa — um bom caminho para transformar esses conceitos em prática do dia a dia.
