Índices: quando ajudam e quando atrapalham

O problema

Índice costuma entrar na conversa como solução mágica.

A query ficou lenta?

• cria índice

O relatório demora?

• cria índice

O endpoint está sofrendo?

• cria índice

Isso parece pragmático.

Mas muitas vezes só troca um problema visível por três problemas mais escondidos:

• escrita mais cara
• mais espaço consumido
• manutenção maior em toda atualização

Então o problema não é “índice funciona ou não funciona”.

O problema é não saber em que tipo de consulta ele realmente ajuda e em que cenário ele só adiciona peso.

Modelo mental

Pense assim:

índice é uma estrutura auxiliar para achar linhas mais rápido sem vasculhar a tabela inteira.

Essa é a ideia central.

Sem índice, dependendo da consulta, o banco pode precisar olhar dado demais para encontrar o que interessa.

Com índice, ele ganha um caminho mais curto.

Mas esse atalho não nasce de graça.

Sempre que você adiciona índice, o banco também precisa:

• armazenar essa estrutura
• atualizá-la a cada escrita relevante
• decidir quando usá-la

Ou seja:

índice é troca.

Você paga um custo contínuo para acelerar alguns tipos de leitura.

Quebrando o problema

Índice ajuda quando a consulta evita trabalho demais

O ganho aparece quando a consulta consegue usar o índice para reduzir bastante a quantidade de linhas examinadas.

Exemplos comuns:

• buscar pedido por id
• filtrar usuário por email
• listar pedidos por customer_id
• ordenar e paginar por coluna muito usada

O padrão aqui é simples:

• existe filtro frequente
• existe caminho claro de busca
• existe redução real do trabalho

Nesses casos, o índice costuma fazer bastante diferença.

Índice ruim é índice que pouca consulta usa

Tem índice que nasce bonito e morre inútil.

Exemplo clássico:

• colocar índice em coluna consultada raramente

Ou:

• colocar índice em coluna com pouca variação, como status, quando quase todas as linhas compartilham poucos valores

Se o índice não ajuda o banco a descartar muita coisa, o ganho pode ser pequeno ou nulo.

E aí você fica com o custo da manutenção sem colher aceleração relevante.

Escrita também paga a conta

Esse é o pedaço que muita gente esquece.

Quando você faz:

• insert
• update
• delete

o banco não mexe só na tabela.

Ele também precisa ajustar os índices relacionados.

Então quanto mais índice você coloca, mais caro tende a ficar o fluxo de escrita.

Em sistema com muita leitura e pouca escrita, isso pode ser aceitável.

Em sistema com escrita alta, índice demais pode virar parte do problema.

Nem consulta lenta pede índice

Esse erro é bem comum.

Às vezes a consulta está lenta por motivos como:

• filtro mal desenhado
• join exagerado
• select * desnecessário
• paginação ruim
• ORM gerando query torta
• modelagem que força leitura complicada

Se você indexa cedo demais, pode até melhorar um pouco o sintoma.

Mas mantém a causa real viva.

Por isso, maturidade aqui costuma começar com:

• medir a consulta
• entender o plano
• ver onde o banco está gastando tempo

Só depois faz sentido discutir índice.

Ordem importa mais do que parece

Esse ponto costuma aparecer rápido em prática real.

Não basta “ter índice nas colunas”.

Dependendo do caso, importa:

• qual coluna vem primeiro
• se a consulta filtra ou ordena na mesma direção
• se o padrão de acesso bate com a estrutura do índice

Então criar três índices isolados nem sempre resolve uma consulta que filtra por combinação de campos.

Às vezes o índice útil é composto.

Às vezes o índice composto está em ordem errada e ajuda menos do que parecia.

Você não precisa decorar banco por banco aqui.

Precisa só entender a ideia:

índice bom conversa com a consulta real, não com a intuição do autor.

Índice também é custo de manutenção mental

Além do banco, o time paga um preço.

Quanto mais índice, mais você precisa lembrar:

• por que ele existe
• que consulta ele protege
• se ainda faz sentido
• se o padrão de acesso mudou

Índice sem dono vira entulho.

No começo ninguém remove porque “vai que ajuda”.

Depois a base acumula peso sem clareza.

Exemplo simples

Imagine uma tabela orders com milhões de linhas.

Uma tela administrativa sempre faz:

• filtrar por customer_id
• ordenar por created_at desc
• paginar

Sem um índice adequado, o banco pode gastar tempo demais procurando e ordenando.

Se você cria um índice alinhado com esse padrão de acesso, a leitura tende a melhorar bastante.

Agora imagine outra decisão:

• colocar índice em status

Se status só tem poucos valores como:

• pending
• paid
• cancelled

e metade da tabela está em paid, esse índice pode ajudar muito menos do que alguém esperava.

Você criou custo de manutenção com benefício limitado.

Aqui está a diferença:

o primeiro índice conversa com um caminho real de busca.

O segundo parece intuitivo, mas talvez não reduza trabalho suficiente.

Erros comuns

Indexar por reflexo

“A query está lenta” não é diagnóstico suficiente.

Ignorar custo de escrita

Cada índice novo pesa também em insert, update e delete.

Olhar só para a coluna e não para a consulta

Índice útil depende do padrão completo de acesso.

Deixar índice virar lixo histórico

Se ninguém sabe por que ele existe, ele provavelmente merece revisão.

Tentar resolver modelagem ruim com índice

Às vezes o banco está só sofrendo com uma estrutura ou query mal pensada.

Como um senior pensa

Um senior tende a puxar a conversa para perguntas como:

• qual consulta está doendo?
• com que frequência ela roda?
• quantas linhas estão sendo examinadas?
• o sistema lê muito mais do que escreve?
• esse índice reduz trabalho suficiente para valer o custo?

Repare no padrão.

Não é:

• “índice sempre ajuda”

Nem:

• “vamos indexar tudo que aparece no where”

É:

• “que trabalho esse índice está evitando, e quanto estou pagando por isso?”

Esse jeito de pensar costuma evitar tanto o otimismo ingênuo quanto o pessimismo preguiçoso.

O que o entrevistador quer ver

Quando o tema aparece em entrevista, o avaliador geralmente quer ver se você entende índice como trade-off real.

Ele tende a procurar sinais como:

• você sabe explicar o que o índice evita
• você lembra do custo em escrita
• você diferencia consulta ruim de falta de índice
• você não trata índice como resposta universal

Uma resposta forte costuma ter esta forma:

1. explicar que índice acelera certos caminhos de leitura
2. lembrar que isso aumenta custo de manutenção
3. dizer que decisão depende da consulta real e do padrão de acesso
4. comentar que medição vem antes de reflexo

Se você responder nessa linha, já demonstra bem mais maturidade do que quem só diz:

• “eu criaria um índice para melhorar performance”

Índice bom não é o que existe. É o que evita trabalho suficiente para pagar o próprio custo.

Quando falta critério, índice vira a gambiarra mais elegante da base.