O que é um Índice de Banco de Dados?

Um índice de banco de dados é uma estrutura de busca ordenada que permite à engine encontrar as linhas certas diretamente, em vez de varrer a tabela inteira. A analogia do livro é exata: ninguém encontra “idempotência” num livro de 900 páginas lendo o livro — a pessoa consulta o índice e pula para a página. Bancos de dados fazem a mesma escolha em cada query, e poder pular ou não é a diferença mais comum entre uma query de 5 milissegundos e uma de 5 segundos.

Principais pontos

O índice, criado e sentido

-- O cavalo de batalha: um índice composto com o formato da query quente
CREATE INDEX orders_pending ON orders (status, created_at);

-- Especializações da mesma ideia:
CREATE UNIQUE INDEX users_email ON users (email);         -- constraint + velocidade
CREATE INDEX unshipped ON orders (created_at)
  WHERE shipped = false;                                  -- parcial: só o subconjunto quente

-- O antes/depois, pelo plano:
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at > now() - interval '1 day';
--  antes:   Seq Scan on orders   (linhas examinadas: 4.812.309)
--  depois:  Index Scan using orders_pending   (linhas examinadas: 1.214)

O código de aplicação encontra a mesma física pela forma da query — esta query é a especificação do índice (status, createdAt), seja qual for a superfície que a escreve:

// JavaScript / Node.js — Back4app JS SDK
// The query shape tells you the index: (status, createdAt)
const query = new Parse.Query('Order');
query.equalTo('status', 'pending');       // equality first…
query.greaterThan('createdAt', since);    // …then the range
query.descending('createdAt');            // …sorted by the same column
const backlog = await query.find();
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

// Flutter / Dart — Back4app Flutter SDK
// The query shape tells you the index: (status, createdAt)
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'pending')      // equality first…
  ..whereGreaterThan('createdAt', since)   // …then the range
  ..orderByDescending('createdAt');        // …sorted by the same column
final response = await query.query();
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

// iOS / Swift — Back4app Swift SDK
// The query shape tells you the index: (status, createdAt)
let query = Order.query("status" == "pending", "createdAt" > since)
  .order([.descending("createdAt")])
query.find { result in
  if case .success(let backlog) = result { render(backlog) }
}
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

// Android / Kotlin — Back4app Android SDK
// The query shape tells you the index: (status, createdAt)
val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "pending")     // equality first…
query.whereGreaterThan("createdAt", since)  // …then the range
query.orderByDescending("createdAt")        // …sorted by the same column
query.findInBackground { backlog, e -> if (e == null) render(backlog) }
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

Como o salto funciona

A estrutura padrão em toda parte é a B-tree: rasa, ordenada, autobalanceada — três ou quatro níveis cobrem centenas de milhões de entradas, e as suas folhas são encadeadas, razão pela qual uma mesma estrutura atende igualdade, ranges e ORDER BY. Essa versatilidade é o motivo de “na dúvida, B-tree” ser o conselho permanente, com as alternativas atuando como especialistas.

B-tree vs. hash vs. os especialistas

Qual tipo de índice você deveria usar?

Duas regras carregam a linha do composto: a regra do prefixo à esquerda — um índice em (a, b, c) atende a, (a, b), (a, b, c), nunca b sozinho — e igualdade primeiro, range/ordenação por último na ordem das colunas (o mnemônico ESR na indexação de bancos de documentos, onde as mesmas B-trees fazem o mesmo trabalho).

Quando indexar — e quando não

Indexe: colunas em filtros WHERE frequentes; chaves de join e campos de ponteiro (algumas engines nunca indexam foreign keys automaticamente — um clássico table scan silencioso); colunas de ORDER BY em caminhos quentes; e sempre com a seletividade em mente — uma coluna de e-mail (milhões de valores distintos) se paga, um flag de status (três valores) em geral não se paga sozinho, embora brilhe liderando um composto com um range atrás. Não indexe: tabelas pequenas que a engine varre mais rápido do que busca; tabelas quentes de escrita além dos poucos índices essenciais; colunas já atendidas pelo prefixo esquerdo de um índice existente; e qualquer coisa para a qual você não consegue nomear uma query — índice sem query é puro imposto de escrita. O ciclo de auditoria: rode EXPLAIN nas queries lentas procurando scans, confira as estatísticas de uso para achar índices mortos, adicione e remova de acordo.

Casos de uso comuns

• A query da lista quente. Filtros de status + data atrás de todo dashboard e feed — o território natural do índice composto.
• Campos de login e lookup. E-mail, username, IDs externos — índices únicos fazendo constraint e velocidade ao mesmo tempo.
• Caminhos de join e ponteiro. Toda foreign key e todo ponteiro que as suas queries percorrem; o cúmplice silencioso do problema N+1 é um deles sem índice.
• Filtros multi-tenant. Compostos liderados pelo tenant — a regra da arquitetura multi-tenant de que todo índice começa com tenant_id.
• Busca e geo. Índices invertidos e espaciais movendo as queries que B-trees não atendem.

Você deveria adicionar esse índice? Matriz de decisão

A disciplina em uma frase: índices são criados em resposta a queries, revisados contra o uso real e removidos sem sentimentalismo.

Limitações e trade-offs

• A escrita paga pela leitura. Cada índice é mais uma estrutura que toda escrita precisa manter — cargas em lote notoriamente rodam mais rápido com os índices derrubados e reconstruídos depois.
• O armazenamento é real. Índices comumente rivalizam com o tamanho da própria tabela; covering indexes, em especial, trocam disco por velocidade.
• Quem decide é o otimizador, não você. Um índice de baixa seletividade pode ser ignorado com razão; estatísticas desatualizadas podem ignorar sem razão um índice bom — o plano é a verdade.
• Erros de ordem neutralizam compostos. (created_at, status) e (status, created_at) são ferramentas diferentes; a regra do prefixo à esquerda não perdoa nada.
• Índice não conserta a query. Wildcards no início, funções sobre colunas e loops N+1 derrotam a indexação por cima — a forma da query vem primeiro.

Índices no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A gestão de índices mora junto com o schema no dashboard: crie, revise e remova índices por classe — de campo único ou compostos — no armazenamento com MongoDB que as suas queries de SDK realmente acessam, seguindo a mesma lógica de B-tree e ESR acima. A query das abas de código e o índice que a atende são desenhados no mesmo lugar — exatamente onde a disciplina de “indexe o que você consulta” quer morar.