Eu também suponho que você esteja usando Oracle. E também recomendo que você confira a página da web do plano de explicação, para começar. Há muito para otimizar, mas pode ser aprendido.
Seguem algumas dicas:
Primeiro, quando alguém o encarrega de otimizar, quase sempre está procurando um desempenho aceitável em vez do desempenho final. Se você puder reduzir o tempo de execução de uma consulta de 3 minutos para 3 segundos, não se preocupe em reduzi-lo para 2 segundos, até que seja solicitado.
Segundo, faça uma verificação rápida para garantir que as consultas que você está otimizando estejam logicamente corretas. Parece absurdo, mas não posso dizer o número de vezes que me pediram conselhos sobre uma consulta de execução lenta, apenas para descobrir que ocasionalmente estava dando respostas erradas! E, como se vê, a depuração da consulta muitas vezes acabava por acelerá-la também.
Em particular, procure a frase "União Cartesiana" no plano de explicação. Se você vê-lo lá, as chances são muito boas de que você encontrou uma junção cartesiana não intencional. O padrão usual para uma junção cartesiana não intencional é que a cláusula FROM lista tabelas separadas por vírgula e as condições de junção estão na cláusula WHERE. Exceto que uma das condições de junção está ausente, de modo que o Oracle não tem escolha a não ser realizar uma junção cartesiana. Com tabelas grandes, isso é um desastre de desempenho.
É possível ver um Cartesian Join no plano de explicação onde a consulta está logicamente correta, mas associo isso a versões mais antigas do Oracle.
Procure também o índice composto não utilizado. Se a primeira coluna de um índice composto não for usada na consulta, o Oracle poderá usar o índice de forma ineficiente ou não usar. Deixe-me dar um exemplo:
A consulta foi:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(O DBMS não era Oracle, então a sintaxe era diferente e esqueci a sintaxe original).
Uma rápida olhada nos índices revelou um índice em Clientes com as colunas (País, Estado, CEP) nessa ordem. alterei a consulta para ler
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
e agora ele foi executado em cerca de 6 segundos em vez de cerca de 6 minutos, porque o otimizador foi capaz de usar o índice com vantagem. Perguntei aos programadores de aplicativos por que eles omitiram o país dos critérios, e esta foi a resposta deles:eles sabiam que todos os endereços tinham país igual a 'EUA', então acharam que poderiam acelerar a consulta deixando esse critério de fora!
Infelizmente, otimizar a recuperação do banco de dados não é realmente o mesmo que reduzir microssegundos do tempo de computação. Envolve entender o design do banco de dados, especialmente os índices, e pelo menos uma visão geral de como o otimizador faz seu trabalho.
Você geralmente obtém melhores resultados do otimizador quando aprende a colaborar com ele em vez de tentar ser mais esperto que ele.
Boa sorte para acelerar a otimização!
