Otimização de Banco de Dados: 13 Técnicas para Reduzir Latência

Latência alta em banco de dados é um gargalo comum: a aplicação responde devagar, o usuário desiste, e o suporte recebe reclamações. A boa notícia é que a maioria das causas tem solução prática, sem exigir um especialista em cada detalhe. Neste guia, listamos 13 otimizações de banco de dados que reduzem a latência, da mais imediata à mais estrutural. Você pode aplicar várias delas ainda hoje.

1. Crie índices nos campos usados em WHERE e JOIN

Índices são a primeira linha de defesa contra consultas lentas. Eles funcionam como um sumário: em vez de ler a tabela inteira, o banco localiza os registros relevantes direto. Crie índices para colunas que aparecem em filtros (WHERE) e junções (JOIN), mas evite exagerar: cada índice extra custa espaço e lentidão em inserções. Um critério prático: comece pelos campos com alta cardinalidade, como CPF ou e-mail, e meça o ganho.

2. Evite SELECT * em produção

Buscar todas as colunas de uma tabela parece inofensivo, mas desperdiça I/O e memória, especialmente quando a tabela tem campos grandes como BLOB ou TEXT. Em vez de SELECT *, liste apenas as colunas que a aplicação realmente usa. Isso reduz o volume de dados transferidos entre o banco e o servidor, cortando a latência de rede. Em uma tabela com 50 colunas, a diferença pode ser de 40% menos dados trafegados.

3. Use EXPLAIN para entender o plano de execução

Antes de otimizar às cegas, pergunte ao banco como ele executa suas consultas. O comando EXPLAIN mostra se a consulta usa índice, faz varredura total da tabela ou usa temporários. Com esse diagnóstico, você ataca a causa certa: se o plano mostra 'seq scan', um índice resolve; se mostra 'sort', talvez um índice composto ajude. É uma prática que separa otimização de tentativa e erro.

4. Otimize consultas com paginação eficiente

Paginacão com OFFSET fica mais lenta conforme a página avança, porque o banco lê e descarta registros anteriores. Em listas grandes, troque por paginação baseada em cursor, usando um campo único como WHERE id > ultimo_id ORDER BY id LIMIT 20. Essa técnica mantém a latência estável mesmo em tabelas com milhões de linhas, em vez de crescer a cada clique.

5. Configure o cache de consultas e de buffer

Bancos como MySQL e PostgreSQL têm caches internos que guardam resultados e páginas de dados em memória. Ajustar o tamanho do buffer pool (no MySQL, innodb_buffer_pool_size) para caber os dados mais acessados reduz leituras em disco, que são ordens de magnitude mais lentas que a RAM. Um valor inicial comum é 70% da memória disponível, mas monitore o hit ratio para calibrar.

6. Normalize e desnormalize com equilíbrio

Normalização elimina redundância, mas joins demais custam caro. Para relatórios e leituras frequentes, considere desnormalizar: crie colunas derivadas ou tabelas resumo que já tragam o dado pronto. O equilíbrio é a chave: mantenha a escrita normalizada e a leitura desnormalizada, usando triggers ou jobs para atualizar os resumos. Em um dashboard de vendas, por exemplo, uma tabela agregada diária responde em milissegundos, enquanto um join de 5 tabelas leva segundos.

7. Use particionamento para tabelas grandes

Tabelas com dezenas de milhões de linhas ficam lentas mesmo com índices. O particionamento divide a tabela em pedaços menores, por data ou por chave, e o banco só varre a partição relevante. Por exemplo, uma tabela de logs particionada por mês faz consultas de um período específico ignorarem os outros meses. A manutenção também fica mais simples: descartar uma partição antiga é mais barato que deletar linhas uma a uma.

8. Evite funções em colunas no WHERE

Escrever WHERE YEAR(data) = 2024 impede o uso de índice na coluna data, forçando uma varredura completa. Reestruture para WHERE data BETWEEN '2024-01-01' AND '2024-12-31', que permite ao banco usar o índice. Esse pequeno ajuste pode reduzir a latência de uma consulta de segundos para milissegundos, sem mudar o resultado.

9. Limite o uso de subconsultas correlacionadas

Subconsultas que dependem da linha externa (correlacionadas) executam uma vez para cada registro, multiplicando o trabalho. Prefira JOINs ou subconsultas simples no FROM. Em uma tabela de 10 mil clientes, uma subconsulta correlacionada pode gerar 10 mil execuções internas; um JOIN resolve em uma passagem. Reescrever esse tipo de consulta costuma dar ganhos imediatos.

10. Monitore queries lentas com logs

Bancos têm logs de slow query que registram consultas acima de um limite de tempo, por padrão 10 segundos no MySQL. Baixe esse limite para 1 segundo em ambientes de teste e analise as queries que aparecem com frequência. Elas são seus maiores vilões de latência. Ferramentas como o Performance Schema (MySQL) ou pg_stat_statements (PostgreSQL) ajudam a rankear as consultas mais custosas.

11. Use conexões persistentes com pool

Abrir e fechar conexão a cada requisição custa caro em termos de handshake e autenticação. Um pool de conexões mantém um conjunto de conexões abertas e reutilizáveis, reduzindo a latência de rede em até 70% em aplicações web. Bibliotecas como HikariCP (Java) ou PgBouncer (PostgreSQL) fazem isso sem mudar o código da aplicação, apenas na configuração.

12. Considere cache em memória externo (Redis)

Para dados lidos com frequência e raramente alterados, um cache externo como Redis pode responder em menos de 1 milissegundo, contra 10 a 50 ms de um banco tradicional. A estratégia é simples: na primeira leitura, busque no banco e guarde no cache; nas seguintes, leia do cache. Dados de configuração, listas de categorias e sessões de usuário são candidatos ideais. Cuidado apenas com a invalidação: defina um TTL para evitar dados obsoletos.

13. Faça manutenção regular de índices e estatísticas

Com o tempo, índices ficam fragmentados e as estatísticas que o otimizador usa para escolher o plano de execução ficam desatualizadas. Rode ANALYZE (ou equivalente) após cargas grandes e reconstrua índices periodicamente. Essa manutenção preventiva evita que o banco tome decisões ruins, como ignorar um índice eficiente. Em um banco com milhões de registros, um ANALYZE semanal mantém a performance estável.

Qual otimização escolher primeiro?

Se você está começando, priorize a criação de índices (item 1) e a reescrita de consultas com SELECT * (item 2). Ambas são rápidas, de baixo risco e dão ganho imediato. Depois, monitore com EXPLAIN e slow query logs para identificar os próximos gargalos. Para sistemas com volume alto, combine o pool de conexões (item 11) e o cache em Redis (item 12), que reduzem a carga no banco sem exigir mudanças estruturais profundas.

FAQ

O que é otimização de banco de dados?

É o conjunto de práticas que melhora a performance de consultas e operações, reduzindo o tempo de resposta e o uso de recursos. Inclui desde ajustes em índices e consultas até configuração de memória e cache.

Como saber se meu banco está lento?

Monitore o tempo de resposta das consultas mais frequentes e use logs de slow query. Se uma consulta que deveria levar milissegundos leva segundos, há um gargalo. Ferramentas como EXPLAIN ajudam a identificar a causa.

Qual a diferença entre normalizar e desnormalizar?

Normalizar organiza dados em tabelas menores e sem redundância, mas exige joins. Desnormalizar adiciona redundância para acelerar leituras. O ideal é equilibrar: escrever normalizado e ler desnormalizado quando necessário.

Cache em memória substitui o banco de dados?

Não. O cache é uma camada auxiliar para dados de leitura frequente. O banco continua sendo a fonte de verdade. Use cache para reduzir a carga, mas mantenha a consistência com TTLs e estratégias de invalidação.

Preciso de hardware melhor para otimizar o banco?

Nem sempre. Muitas otimizações são de configuração e código, como índices e consultas. Hardware ajuda, mas só depois de esgotar as melhorias lógicas. Um banco mal otimizado fica lento mesmo em máquinas potentes.

Com que frequência devo fazer manutenção no banco?

Depende do volume de escrita. Em bancos com muitas inserções e atualizações, rode ANALYZE semanalmente e reconstrua índices a cada mês. Em bancos menores, uma manutenção mensal já é suficiente. Monitore para ajustar a frequência.