Como escolher o tipo certo de índice

A gente já mergulhou na teoria dos índices, conheceu os tipos, aprendeu a criar e remover, e também entendeu como indexar tipos de dados mais complexos, tipo arrays e JSONB. Agora chegou a hora de falar sobre como escolher aquele índice que realmente vai funcionar bem pra tua situação — porque escolher errado pode dar muita dor de cabeça.

Pensa que teu banco de dados é uma biblioteca, e as queries são visitantes procurando livros. Se os livros tão jogados no chão, achar alguma coisa vira uma missão impossível. Índices são tipo prateleiras e catálogos organizados, que ajudam a encontrar o que tu quer rapidinho, sem ter que olhar tudo.

Mas se tu coloca a prateleira errada ou o catálogo errado, tipo usar um índice HASH onde precisava de um índice pra busca por faixa, é como se o bibliotecário tentasse achar livros pelo nome, mas só tivesse um catálogo pelo ano de publicação — vai demorar, e todo mundo vai reclamar. No banco de dados, isso vira query lenta e o sistema sofrendo.

Hoje a ideia é mostrar como escolher o índice certo pra tua query voar e o banco não sofrer. Se tu errar, o resultado é triste: query lenta, recurso indo pro saco, e o bibliotecário (PostgreSQL) deprimido.

Critérios pra escolher índice: checklist

Quando for escolher um índice, responde essas perguntas:

1. Qual o tipo de dado dessa coluna?
   • Por exemplo, números INTEGER, FLOAT normalmente vão de B-TREE, arrays — GIN, campos de texto — aí depende do caso.

2. Que tipo de query tu faz mais?

   • WHERE field = value? Busca direta? Provavelmente B-TREE ou HASH vai servir.
   • Busca em arrays ou JSONB? Olha pro GIN.
   • Dados geográficos, faixas? Pensa em GiST.

3. O que rola com teus dados?

   • Se tua tabela recebe muita inserção e update, evita indexar demais, porque isso pesa no desempenho.

4. Precisa garantir unicidade?

   • Nesse caso, tem que usar índice com atributo UNIQUE.

Casos: exemplos reais de escolha de índice

Bora ver uns cenários reais.

1. Busca simples por igualdade

Tu trabalha com um banco de estudantes e quer achar rápido um estudante pelo email:

SELECT * FROM students WHERE email = 'student@example.com';

O que importa aqui? A busca é por igualdade. O melhor é o índice B-TREE, que é ótimo pra busca de valor exato.

CREATE INDEX idx_students_email ON students (email);

Ou, se o email tem que ser único:

CREATE UNIQUE INDEX idx_students_email_unique ON students (email);

2. Busca por faixa

Agora imagina que tu quer achar estudantes com mais de 18 anos:

SELECT * FROM students WHERE age > 18;

Pra busca por faixa, B-TREE também é ótimo, porque a estrutura dele é feita pra busca ordenada.

CREATE INDEX idx_students_age ON students (age);

3. Filtrando por arrays

Tu tem uma tabela courses, e numa coluna guarda um array com os IDs dos estudantes inscritos no curso. Tu quer achar todos os cursos onde o estudante com ID 123 tá inscrito.

SELECT * FROM courses WHERE student_ids @> ARRAY[123];

Pra esse tipo de query, o índice GIN é perfeito, porque foi feito pra trabalhar com arrays.

CREATE INDEX idx_courses_students_ids ON courses USING gin (student_ids);

4. Buscando dados em JSONB

Digamos que tu tem uma tabela com dados em JSONB, guardando info dos pedidos. Tu quer achar todos os pedidos onde o cliente é da cidade "Moscow":

SELECT * FROM orders WHERE data->>'city' = 'Moscow';

Aqui o índice GIN também manda bem, porque ele busca rápido por chave e valor em JSONB.

CREATE INDEX idx_orders_data ON orders USING gin (data);

5. Dados geográficos

Se tu trabalha com info geográfica, tipo achar todos os pontos dentro de um raio, usa índice GiST. Esse tipo de índice é show pra geometria e faixas.

CREATE INDEX idx_locations_geom ON locations USING gist (geom);

Comparando performance dos índices

Pega um exemplo real: busca de estudantes por email. A tabela tem 1 milhão de registros. Vamos rodar a query com diferentes índices e sem índice:

Resumo: nesse caso, usar índice B-TREE deixa a query mais de 500 vezes mais rápida.

Erros na escolha de índices

O erro mais comum é criar índice "por via das dúvidas". Tipo, tu indexa toda coluna da tabela e depois vê que inserir ficou lento. Lembra: índice não é mágica que resolve tudo. É uma ferramenta poderosa, mas se usar errado, só atrapalha.

Outro erro clássico é escolher o tipo errado de índice. Por exemplo, tu usa HASH pra busca por faixa, e as queries ficam lentas. Isso porque HASH só serve pra busca exata.

Dicas pra escolher índice

• Se tu faz muito busca por igualdade ou ordenação, vai de B-TREE.
• Pra busca exata e quer economizar memória, pode usar HASH.
• Se trabalha com arrays ou JSONB, tua escolha é GIN.
• Pra faixas ou dados geográficos, usa GiST.

E o mais importante: sempre analisa tuas queries! Usa EXPLAIN e EXPLAIN ANALYZE pra ver como o PostgreSQL tá usando os índices e o que dá pra melhorar.

EXPLAIN ANALYZE
SELECT * FROM students WHERE email = 'student@example.com';

É isso por hoje! Agora tu tá pronto pra escolher índices como um jedi escolhe o sabre de luz. Vai com calma, não cria índice à toa, e sempre confere o impacto na performance.