# Índice de banco de dados: 6 tipos que você precisa conhecer

> Published 2026-10-11T13:56:38.823Z on https://www.crazystack.com.br/pt/p/indice-de-banco-de-dados-6-tipos-que-voce-precisa-conhecer/
> Source video: https://www.youtube.com/watch?v=COurbijFW-o

Um índice de banco de dados é uma estrutura de dados extra que acelera buscas na tabela, ao custo de escritas mais lentas e mais espaço em disco. Você escolhe as colunas com base no padrão de acesso da aplicação: o que é buscado com frequência merece índice, o resto não.

## O que é um índice de banco de dados

Um índice de banco de dados é uma estrutura de dados subjacente que acelera o acesso às linhas de uma tabela. Quando você cria uma tabela com chave primária, o banco já cria um índice nela automaticamente. No [PostgreSQL](https://www.postgresql.org/docs/current/indexes.html), o PostgreSQL da The PostgreSQL Global Development Group, isso acontece sempre na chave primária, e você não precisa fazer nada.

SQL armazena dados em linhas e colunas. Numa tabela com id, nome, e-mail e created_at, cada linha fica gravada em sequência. O índice cria uma estrutura adicional, guardada junto com os dados. Ela ocupa espaço extra, mas serve como um atalho para encontrar valores sem ler tudo.

Sem índice, buscar o nome "Fernando" força um full table scan: o banco percorre linha por linha até achar o resultado. É custoso e lento em tabelas grandes. É exatamente esse problema que o índice existe para eliminar.

## Como a B-tree acelera a busca por ID

O índice padrão do PostgreSQL é o B-tree, um tipo de árvore balanceada que organiza valores de forma ordenada. Conforme você insere IDs 1, 2, 3, 4, 5, a estrutura se reordena automaticamente para manter a busca eficiente. Em 2026, a documentação oficial do PostgreSQL segue recomendando o B-tree como tipo default para a maioria dos casos.

A busca funciona por comparações. Para achar o ID 7, o banco pergunta: 7 é maior ou menor que 4? Maior, vou para a direita. Maior ou menor que 6? Maior, sigo adiante. Foram três etapas para encontrar o valor, contra sete leituras na tabela sem índice.

O B-tree também é muito bom em buscas por faixa (range). Se você pede todos os IDs entre 1 e 3, eles já estão "juntinhos" na árvore por causa da ordenação. O mesmo vale para created_at: com índice nesse campo, encontrar registros criados entre duas datas é trivial.

## O preço do índice: escritas mais lentas e mais espaço

Todo índice tem custo. A estrutura extra ocupa espaço em disco, então a tabela fica necessariamente mais pesada. E cada inserção precisa atualizar o índice, o que torna a criação de novos registros mais lenta.

Essa reordenação do B-tree a cada inserção tem custo computacional. Por isso ninguém cria índice em tudo: se você não executa muitas buscas sobre aquela coluna, o índice só adiciona peso e lentidão de escrita sem devolver nada em troca.

A regra de ouro é simples: o índice é ditado pelo padrão de acesso. Numa rede social, você busca por @username muito mais vezes do que cria usuários novos. Busca frequente e inserção rara é o cenário perfeito para um índice na coluna de username.

## Tipos de índice e quando usar cada um

O B-tree é o mais comum, mas não é o único. A [documentação de tipos de índice do PostgreSQL](https://www.postgresql.org/docs/current/indexes-types.html) descreve as famílias disponíveis, e cada uma serve um padrão de acesso diferente. A tabela abaixo resume as opções mais úteis no dia a dia.

| Tipo | Melhor uso | Limitação principal |
| --- | --- | --- |
| B-tree | Busca exata e por faixa, ordenação | Escrita e espaço extras |
| Hash | Match exato, complexidade média O(1) | Não serve para range, ordenação ou prefixo |
| Composto | Consultas que filtram duas colunas juntas | Só ajuda se a ordem das colunas bate com a query |
| Parcial (filtrado) | Subset da tabela acessado com frequência | Só indexa linhas que atendem à condição |
| Full text | Busca dentro de textos completos | Armazenamento pesado, mapeia cada token |
| Espacial | Geolocalização, como restaurantes num raio de 2 km | Inútil fora de casos com coordenadas |

O índice hash funciona como um hash map: a função hash sempre gera a mesma chave para o mesmo valor, e a busca tem complexidade média O(1). A contrapartida é que ele exige match exato. Procurar nomes que começam com "Augus" não funciona com hash.

Esses conceitos se combinam sem conflito. Um índice composto sobre name e e-mail, por padrão, ainda é um B-tree; "composto" diz respeito apenas a quais colunas são indexadas. Da mesma forma, um índice único apenas impede valores duplicados, e um índice parcial só inclui as linhas que passam na condição definida.

## Como decidir se vale a pena criar o índice

Decidir exige olhar a aplicação, não a tabela. Pergunte com que frequência cada busca acontece e como ela é feita. O material de referência clássico sobre esse raciocínio é o livro [Use The Index, Luke](https://use-the-index-luke.com/), de Markus Winand, que detalha exatamente como o índice atende padrões de acesso.

Um caminho prático de decisão:

1. Liste as queries mais executadas pela aplicação.
2. Verifique se cada uma já é atendida por um índice existente, como o da chave primária.
3. Para as que não são, escolha o tipo: B-tree para faixa e prefixo, hash para match exato, parcial quando só um subset importa.
4. Meça antes e depois, observando o impacto tanto na leitura quanto na escrita.

Se o seu caso exige match parcial de texto, o B-tree é o caminho natural. Se exige só igualdade exata, hash pode ser mais rápido. Se o domínio é geográfico, o índice espacial é o único que faz sentido. Índice é sempre criado com base no padrão de acesso e na necessidade da aplicação, nunca por precaução.

## Perguntas frequentes sobre índices

- **O banco cria índice na chave primária automaticamente?** Sim. No PostgreSQL, toda chave primária recebe um índice automaticamente. Em outras chaves, como e-mail ou username, a criação é responsabilidade sua.

- **Por que não criar índice em todas as colunas?** Porque cada índice ocupa espaço e desacelera inserções. Se a coluna não é alvo de buscas frequentes, o índice só adiciona custo sem benefício.

- **Índice hash serve para busca por prefixo?** Não. O índice hash só funciona com match exato. Para buscas por prefixo, faixa ou ordenação, o B-tree é a escolha adequada.

- **Índice composto substitui o B-tree?** Não. São conceitos independentes: composto define quais colunas são indexadas, B-tree define a estrutura de dados usada. Um índice composto padrão utiliza B-tree por baixo.

- **Índice único e índice parcial podem coexistir?** Sim. Unicidade impede valores duplicados; parcial restringe quais linhas entram no índice. As propriedades se combinam livremente com o tipo de estrutura escolhido.

## Do vídeo para o artigo: transforme suas explicações

Índices resolvem o problema de encontrar informação rápida num banco de dados; o desafio do criador de conteúdo é parecido: fazer quem busca encontrar seu conhecimento. Se você explica conceitos assim em vídeos, como o canal do Gustavo Dev Doido faz com material do [Crazystack Typescript](https://crazystack.com.br) e do Bootcamp do Dev Doido, esse conteúdo merece também uma versão escrita que os buscadores consigam indexar.

É exatamente isso que o [Skala Blog](https://skalablog.com) faz. Você cola a URL de um vídeo do YouTube, a ferramenta transcreve e gera um artigo estruturado, pronto para revisar e publicar.

[Source video](https://www.youtube.com/watch?v=COurbijFW-o)