Checklist de otimização database: 12 passos práticos

Otimizar um banco de dados não é evento único, é rotina. Se você chegou até aqui, provavelmente já enfrentou uma query que demora segundos, um relatório que trava ou um pico de CPU sem explicação. Este checklist é para quem precisa agir com método, sem chutar configuração ou sair criando índice por conta própria. Use-o antes de uma migração, depois de uma reclamação de lentidão ou na revisão trimestral de performance. Ele funciona para MySQL, PostgreSQL, SQL Server e Oracle, com adaptações pontuais.

1. Diagnóstico inicial: medir antes de tocar

Identifique as queries mais lentas

Ative o log de queries lentas ou use uma ferramenta de monitoramento. Sem saber quais consultas consomem mais tempo, você otimiza no escuro. No MySQL, o slow query log mostra exatamente onde começar.

Capture o baseline de performance

Registre tempo médio de resposta, uso de CPU e I/O em horário de pico. Esse número inicial é seu ponto de comparação. Sem ele, não há como saber se a otimização surtiu efeito.

Verifique locks e bloqueios atuais

Consultas que esperam liberação de lock são causa comum de lentidão intermitente. Use a view de processos ativos do seu SGBD para ver o que está travado agora.

2. Índices: onde mora a maior parte do ganho

Revise índices existentes e remova redundâncias

Índice demais também prejudica: cada INSERT e UPDATE precisa atualizá-los. Liste os índices de cada tabela e remova os que nunca são usados pelo plano de execução.

Crie índices para as colunas usadas em WHERE e JOIN

Colunas de filtro e junção são as primeiras candidatas. Mas atenção: índice composto exige ordem correta. A coluna mais seletiva vem primeiro, senão o SGBD ignora parte do índice.

Use EXPLAIN para validar cada índice novo

Antes de aplicar, rode o plano de execução da query. Confirme que o índice proposto é usado. Se o plano continua fazendo full scan, o índice não resolve o problema.

3. Consultas: reescrever antes de escalar hardware

Evite SELECT * em tabelas largas

Buscar colunas desnecessárias aumenta I/O e tráfego de rede. Liste apenas os campos que a aplicação realmente consome. Em tabelas com mais de 30 colunas, o ganho é visível.

Desconfie de funções em colunas indexadas

WHERE DATE(data) = '2024-01-01' impede o uso de índice na coluna data. Reescreva como intervalo: data >= '2024-01-01' AND data < '2024-01-02'. Pequena mudança, grande efeito.

Quebre queries complexas em etapas

Uma query com cinco JOINs e subqueries correlacionadas pode ser substituída por duas consultas simples e uma junção em memória. Teste o custo no seu SGBD antes de decidir.

4. Configuração e manutenção contínua

Atualize estatísticas do otimizador

O otimizador decide o plano de execução com base em estatísticas. Se elas estão desatualizadas, ele escolhe caminhos ruins. Agende atualização automática semanal ou após cargas grandes.

Ajuste o buffer pool ou cache do SGBD

O tamanho do cache de páginas define quantos dados ficam em memória. Se o hit ratio fica abaixo de 95%, aumente o buffer pool com cautela, respeitando a RAM disponível do servidor.

Monitore o crescimento do banco e planeje arquivamento

Tabelas que crescem sem controle degradam a performance de qualquer índice. Defina política de retenção e arquive dados antigos para tabelas separadas ou data warehouse.

5. Hardware e ambiente: o último passo, não o primeiro

Verifique se o disco é o gargalo

Se o I/O wait está alto, um SSD ou um disco com mais IOPS resolve mais que qualquer tuning de query. Meça antes de comprar: use iostat ou ferramentas do SGBD para confirmar.

Confirme se a memória é suficiente para o working set

Se o banco inteiro não cabe em RAM, o SGBD vai buscar dados no disco. Nesse caso, aumentar memória é legítimo. Mas só depois de garantir que índices e queries já estão otimizados.

O erro mais comum na otimização de banco de dados

O erro mais comum é pular o diagnóstico e sair criando índices ou aumentando hardware. Cedo ou tarde, o problema volta, porque a causa raiz continua lá: uma query mal escrita, um índice redundante ou estatística desatualizada. Otimização sem medição é adivinhação. Aplique o checklist na ordem, registre o baseline e compare depois de cada mudança. Só assim você sabe, de fato, o que funcionou.

Perguntas frequentes sobre otimização de banco de dados

Qual a diferença entre otimização de banco e tuning de SQL?

Otimização de banco cobre também configuração, hardware e manutenção. Tuning de SQL é uma parte, focada em reescrever consultas e ajustar índices para melhorar o plano de execução.

Com que frequência devo rodar um checklist de otimização?

Em bancos com carga constante, revise a cada trimestre. Após mudanças grandes, como migração ou nova versão da aplicação, rode o checklist completo na sequência.

Otimizar banco de dados exige derrubar o sistema?

Depende da ação. Criar índice pode travar a tabela em alguns SGBDs. Prefira ferramentas online ou janelas de manutenção para mudanças estruturais. Consultas lentas podem ser ajustadas sem parar o serviço.

Como saber se preciso otimizar banco ou melhorar a aplicação?

Se o problema é uma query específica que demora, o ajuste é no SQL. Se é lentidão generalizada, investigue locks, hardware e configuração. Aplicação mal escrita, com N+1 queries, também gera carga artificial no banco.

O que é hit ratio e por que ele importa?

Hit ratio é o percentual de leituras atendidas pela memória do SGBD, sem acessar disco. Abaixo de 95%, o banco sofre com I/O. Aumentar o buffer pool costuma elevar esse número.

Vale a pena usar ferramentas pagas de monitoramento?

Para bancos críticos, sim. Ferramentas como Database Performance Analyzer da SolarWinds ou o Orientador de Otimização do SQL Server automatizam a detecção de gargalos. Para bancos pequenos, logs e EXPLAIN já resolvem a maior parte.