O otimizador do Firebird Server escolhe um plano de acesso antes de executar cada comando SQL. Este plano de acesso define os passos que o motor do Firebird seguirá para executar o comando e isto tem impacto direto na performance.

Geralmente o otimizador escolherá os melhores caminhos (opções), fazendo uso de índices sempre que possível. Entretanto em alguns casos o otimizador acaba escolhendo um plano de acesso inadequado por diversos motivos, como seguem:

1. A decisão entre usar ou não um índice leva em consideração as estatísticas de valores repetidos no índice. Quanto menos valores repetidos em um índice, maior a probabilidade do otimizador escolhê-lo para o plano de acesso. Para isto o otimizador usa uma estatística que fica gravada em uma das tabelas de sistema, juntamente com a definição do índice. Esta estatística é atualizada automaticamente, mas após muito tempo de uso do banco, ela pode não mais representar a realidade do índice e induzir o otimizador a tomar uma decisão errada. Você pode forçar a atualização da estatística de algumas formas:
   • Executando o comando SET STATISTICS INDEX. Clique aqui mais detalhes!
   • Fazer backup/restauração do banco, pois a reconstrução do banco na restauração faz o recálculo das estatísticas. Mais detalhes aqui.
2. O otimizador pode adotar um plano inadequado quando o comando SQL não está bem organizado. Comandos SQL confusos podem confundir não apenas programadores, mas também o otimizador do Firebird (sim, isto pode acontecer!). Procure escrever os comandos SQL seguindo um raciocínio mais lógico e dificilmente confundirá o otimizador.
3. SQL muito complexo, com dezenas ou centenas de planos possíveis, pode complicar para o otimizador na hora de escolher o melhor plano de acesso. Então, especialmente em SQL complexos, procure organizá-lo aplicando a melhor lógica possível. E se não ficar bom, experimente escrever o SQL de várias formas diferentes que tenham o mesmo resultado. Você poderá se surpreender como a performance pode variar apenas mudando a lógica do SQL.
4. O otimizador, como dito antes, procura adotar planos que faça o máximo uso de índices, pois estes são muito eficientes nas pesquisas. Entretanto se não existem índices adequados, ele escolherá o melhor que encontrar. Por isto é fundamental analisar o plano dos SQLs que estão apresentando lentidão para identificar a necessidade de criação de alguns índices. Cuidado! Chaves primárias, estrangeiras e únicas geralmente já possuem índice e, portanto, não há porque criar índices para as colunas que estão nas chaves. Antes de decidir pela criação de um índice, é necessário analisar bem, pois excesso de índice também causa lentidão (INSERT e UPDATE precisam atualizar os índices).
5. Cuidado com índices compostos. Estes podem ser muito eficientes em alguns casos particulares, mas o Firebird geralmente consegue combinar o uso de vários índices para a mesma busca, obtendo resultados muitas vezes melhores que quando usando índice composto. Se você criar um índice com os campos (A, B), por exemplo, o Firebird não fará uso se o que ele precisa é (B, A), mas se existirem dois índices simples (A) e (B), ele poderá combiná-los como (A, B) ou como (B, A), conforme for mais conveniente para o otimizador. Então, como regra geral, evite índices compostos.
6. Em casos raros, mesmo que tudo pareça perfeito, o otimizador do Firebird poderá escolher um plano ruim (extremamente ruim em alguns casos!). Quando isto acontece, ainda temos a alternativa de ajudar o Firebird informando a ele o plano de acesso através da cláusula PLAIN. Atenção!Talvez você passe a vida inteira trabalhando com Firebird e nunca necessite informar o PLAN. Informar o plano no comando SQL é ruim porque o melhor plano hoje pode se tornar um plano ruim à medida que o banco de dados for crescendo! Então antes de usar esta solução, analise bem todas as outras possibilidades!