Banco lento quase nunca é "o Firebird". É consulta, índice, transação longa, manutenção atrasada, versão antiga ou ambiente. A ordem certa é sempre: medir, achar o gargalo, corrigir.
Seis causas explicam a maior parte dos casos — e cada uma pede uma correção diferente.
A varredura completa da tabela é o motivo nº 1 de lentidão — e normalmente o mais rápido de corrigir.
Estatística desatualizada ou índice inadequado fazem o otimizador escolher o pior caminho.
Uma transação esquecida segura versões antigas de registro e degrada a leitura de todos os usuários.
Base acumulando versões antigas (sweep atrasado) responde cada vez mais devagar.
Versões defasadas ficam sem correções e perdem ganhos de otimizador com bases grandes.
Disco saturado, memória curta, antivírus e backup rodando junto com o sistema em produção.
Antes de "otimizar", é preciso provar onde está o gargalo — com número, não com palpite. É isso que o diagnóstico entrega.
O caminho que o Firebird escolheu para cada consulta que dói: índice, ordem de join, varredura.
Índice com estatística velha entrega plano ruim — medimos e recalculamos.
Quem está segurando as versões antigas: transações longas, conexões esquecidas e sweep atrasado.
Onde o disco é consumido de verdade: leitura de dados, índices, backup e concorrência.
O que a sua versão entrega comparado ao que a atual entrega — e o que o servidor aguenta.
Nenhum desses sintomas se resolve reiniciando o servidor.
As perguntas que mais chegam no dia a dia de quem depende do banco.
Medindo. Plano de execução das consultas que travam, transações abertas e uso real de disco. Sem medir, qualquer mudança é chute — e costuma piorar em outro ponto.
Resolve quando o gargalo é varredura de tabela. Índice inadequado ou índice demais também deixa o banco lento: aumenta o custo de escrita e pode levar o otimizador a escolher o pior caminho.
Não. Sweep é manutenção, não cura: rodar sempre num banco cheio de transações longas só disputa o disco com o sistema em produção. O caminho é descobrir o que gera o lixo.
Só depois de saber onde está o gargalo. Boa parte da lentidão é de banco e consulta — e hardware novo não conserta consulta ruim.
Aí o ganho pode estar na migração de versão, não no tuning. São dois caminhos diferentes: migração e performance.
Me conta o cenário: versão, tamanho da base e quando trava. Eu digo onde está o ganho mais rápido.
