Índices de base de dados explicados:a lista telefónica

Índices de base de dados explicados de forma simples: um índice funciona exatamente como uma lista telefónica: em vez de leres todas as páginas para encontrar um nome, saltas diretamente para ele. Sem índice, a tua base de dados lê cada linha de uma tabela para responder a uma pergunta. Com um, uma consulta real sobre os mesmos dados passou de 2.300 milissegundos para 2,3 — mil vezes mais rápida — porque percorreu as 47 linhas correspondentes em vez de 500.000.

Os índices são a ferramenta de desempenho com mais alavancagem em que alguma vez vais tocar, não exigem nenhuma alteração ao código e a IA esquece-se deles com frequência. Eis o que são, a regra que cobre 90% dos casos e os números reais de produção que mostram o que está em jogo.

Índices de base de dados explicados: o que é um índice?

Pensa em como encontras “Gonçalves” numa lista telefónica. Não começas na página um a ler todas as entradas — aproveitas o facto de a lista estar ordenada, saltas para perto dos G e chegas ao nome em segundos. Agora imagina a mesma lista telefónica com as entradas por ordem aleatória. Encontrar um nome significa ler a lista inteira, sempre, em cada pesquisa.

Essa segunda lista telefónica é uma tabela de base de dados sem índice. As tabelas guardam as linhas sem nenhuma ordem útil, por isso uma pergunta como “mostra-me as tarefas deste cliente” obriga a base de dados a examinar todas as linhas e a guardar as que correspondem — uma leitura completa. Um índice é a lista telefónica ordenada que a base de dados mantém ao lado: uma cópia de consulta rápida de uma coluna (ou de várias) que lhe permite saltar diretamente para as linhas certas.

Traduzido para a experiência do utilizador: 2,3 segundos é uma página que os teus clientes veem a carregar. 2,3 milissegundos é instantâneo. A mesma consulta, os mesmos dados — a única diferença é um índice.

A regra: indexa todas as chaves estrangeiras

Não precisas de te tornar engenheiro de desempenho. Uma regra cobre a esmagadora maioria dos casos reais:

Indexa todas as chaves estrangeiras e todas as colunas pelas quais filtras ou ordenas com frequência.

Uma chave estrangeira é qualquer coluna que aponta para outra tabela — o cliente a que uma tarefa pertence, o projeto que uma fatura cobra, o estado que um registo tem. Numa base de dados bem estruturada (do tipo que obténs ao normalizar como deve ser), estas colunas de referência estão por todo o lado, e são precisamente o que a base de dados usa para ligar tabelas ao responder a perguntas. Cada uma delas leva um índice. Sem exceções, sem juízos de valor.

Para além disso, indexa as colunas pelas quais os teus ecrãs filtram e ordenam constantemente: a organização a que cada linha pertence (a espinha dorsal das apps multi-tenant, filtrada em praticamente todas as consultas), as datas de criação para listas “mais recentes primeiro” e o carimbo temporal de eliminação lógica que quase todas as consultas verificam para esconder registos apagados. O hábito é uma linha por coluna no momento de criar a tabela — CREATE INDEX idx_tasks_project_id ON tasks(project_id); — e é um hábito que a IA não vai manter por ti: os esquemas gerados definem as referências e saltam os índices com frequência, o que funciona na perfeição numa demo com 50 linhas e colapsa com 500.000.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Índices compostos: o segundo truque da lista telefónica

Uma lista telefónica não está ordenada por uma só coisa — está ordenada por apelido e depois por nome próprio. Isso permite-te encontrar todos os “Silva”, ou exatamente “Silva, João”. O que não permite é encontrar todos os “João”, seja qual for o apelido — para isso, voltas a ter de ler a lista inteira.

Um índice composto é a mesma estrutura sobre duas ou mais colunas, e obedece à mesma lei da esquerda para a direita. Um índice sobre (organização, estado) acelera “tudo desta organização” e “tudo desta organização com este estado” — mas não faz nada por “tudo com este estado em todas as organizações”, porque o estado é o nome próprio, não o apelido.

A consequência prática: a ordem das colunas importa. Põe primeiro a coluna pela qual filtras sempre — num produto multi-tenant, é a organização. E os índices compostos têm um poder extra: se a ordem do índice coincidir com a ordenação da tua consulta, os resultados já saem ordenados, saltando por completo o passo de ordenação.

Quando NÃO indexar

Os índices não são gratuitos: cada um ocupa espaço em disco e tem de ser atualizado em cada escrita, por isso cada índice adicional torna as inserções e atualizações um pouco mais lentas. Quatro situações em que os deves dispensar:

Colunas com dois valores. Um indicador verdadeiro/falso divide a tabela mais ou menos ao meio — saltar para “metade da lista” não poupa nada. Tabelas pequenas. Abaixo de cerca de 1.000 linhas, ler a tabela inteira é praticamente instantâneo; a chave primária chega. Colunas que nunca pesquisas. Só as colunas que aparecem em filtros, ordenações ou ligações merecem um índice — notas de texto livre não. Colunas que mudam constantemente em tabelas com muitas escritas. Cada alteração tem também de atualizar o índice; numa tabela que é sobretudo escrita e raramente lida, essa troca corre mal.

A regra de ouro: cada índice deve justificar a sua existência com uma melhoria mensurável numa consulta. Indexar “só por precaução” é como acabas com escritas lentas e disco desperdiçado.

Números reais de produção

Três medições reais de antes e depois, cada uma de um ecrã comum num produto SaaS:

Todas as linhas contam a mesma história: a base de dados deixou de ler tudo e começou a saltar. E o processo que as produziu é repetível por qualquer fundador: encontra o ecrã lento, pede à base de dados que explique como respondeu à consulta (todas as bases de dados têm uma funcionalidade “explain” — e pedir à IA para interpretar o resultado funciona lindamente), acrescenta o índice para o qual a explicação aponta e mede outra vez. Quando o relatório diz “leu 500.000 linhas para devolver 20”, encontraste o índice em falta.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

Como encontro os índices que me faltam?

Segue a lentidão. Quando uma página se arrasta, pega na consulta dela, corre a funcionalidade explain da tua base de dados e procura leituras completas de tabelas — o relatório diz literalmente quantas linhas foram lidas e quantas foram devolvidas. Os painéis das bases de dados modernas também mostram as consultas mais lentas e muitas vezes sugerem logo o índice em falta. Cola qualquer um destes resultados na IA para obteres uma interpretação em linguagem corrente.

Posso ter índices a mais?

Sim. Cada índice cobra uma taxa em cada escrita e ocupa disco, por isso uma tabela com uma dúzia de índices especulativos paga custos reais por consultas hipotéticas. Começa pela regra — chaves estrangeiras, organização, filtros comuns — e acrescenta mais apenas quando uma consulta lenta, medida, o exigir, e elimina os índices que nada usa.

Os índices também aceleram as escritas?

Não — pelo contrário, ligeiramente. Um índice acelera a leitura, mas tem ele próprio de ser atualizado sempre que os dados mudam, por isso as escritas pagam uma pequena taxa por índice. Para um produto SaaS típico, que lê muito mais do que escreve, a troca compensa largamente; só não indexes colunas que nada pesquisa.

A IA acrescenta índices por mim automaticamente?

Às vezes, de forma inconsistente — e esquecer os índices das chaves estrangeiras é uma das falhas mais comuns nos esquemas gerados por IA, porque a demo funciona bem sem eles. Torna-o explícito: diz à IA que cada tabela que criar tem de indexar as chaves estrangeiras e as colunas mais filtradas, e revê o esquema com base nessa regra, como numa checklist.