Bancos de Dados: O Poder (e o Perigo) dos Índices
Sua query que demorava 4 segundos passou a rodar em 50ms. Entenda como as B-Trees funcionam nos índices, por que você deve usá-los e onde não deve aplicá-los.
Você já lançou uma API e, após algumas semanas com os usuários cadastrando dados, as requisições começaram a ficar lentas? O vilão número um costuma ser a ausência de Índices no Banco de Dados.
O Full Table Scan (A Busca Cega)
Se você roda um SELECT * FROM users WHERE email = 'teste@email.com' e a coluna email NÃO tem um índice, o Banco de Dados precisa ler linha por linha desde o registro 1 até o registro 1.000.000 para achar a sua resposta. Isso consome um I/O altíssimo de disco.
A Magia das B-Trees (Árvores Balanceadas)
Quando você adiciona um Índice (Index) na coluna 'email', o banco cria uma estrutura de dados apartada (geralmente uma B-Tree). É como o índice alfabético no final de um livro. Em vez de ler as 500 páginas do livro para achar a palavra 'Node', você vai no Índice, procura a letra N, e ele diz: 'Página 245'.
-- Criando um índice simples no PostgreSQL/MySQL
CREATE INDEX idx_users_email ON users(email);
-- Se a sua regra é que o e-mail não pode repetir:
CREATE UNIQUE INDEX idx_users_email_unique ON users(email);A mesma busca que lia 1 milhão de linhas, agora percorre a árvore B-Tree em 3 ou 4 pulos matemáticos para achar a resposta. O tempo cai de 4 segundos para 50 milissegundos.
O Perigo: Não indexe tudo!
A vontade de um júnior é colocar Índice em todas as colunas da tabela. Mas existe um custo pesado:
- Lentidão na Gravação (INSERT/UPDATE/DELETE): Toda vez que você insere um novo usuário, o banco precisa não só gravar o dado, mas também reorganizar a árvore do índice. Se uma tabela tem 15 índices, um simples Insert vai demorar 15 vezes mais para salvar.
- Consumo de Disco: Índices são estruturas de dados físicas. Eles consomem muito armazenamento. Um índice mal feito pode ficar maior que a própria tabela de dados em Gigabytes.
Regra de Ouro: Indexe apenas colunas que são muito utilizadas na cláusula WHERE (buscas, como status, email, data) ou em JOINs (chaves estrangeiras). Nunca indexe colunas de texto longo (como description) ou de baixa cardinalidade (como booleanos: is_active), a menos que use Partial Indexes.
Conclusão
Dominar os índices (B-Tree, Hash, GiST) é a diferença entre precisar escalar o servidor de banco de dados para pagar US$ 500 por mês ou resolver o mesmo tráfego pagando US$ 20 numa máquina modesta com consultas inteligentes.