Nos últimos meses dedico algum tempo lendo as mensagens postadas nos foros e a tempo estava me
coçando para dar meu palpite, dado aos erros básicos que vejo – que vou tentar lembrar de alguns.
1) fazer um select de todas as linhas da tabela e depois fazer um filtro para pegar um único registro.
Correto: é construir um select que retorna só registros de interesse; Ex: select codigo,nome from
usuario where codigo=’123’
2) fazer pouca gestão sobre índices é um erro; Correto: é você por no banco de dados somente
índices que sejam favoráveis… lembrando, um índice demanda tempo de processamento quando faz
INSERT, UPDATE ou DELETE; O SELECT demanda tempo para o motor do banco de dados
escolher qual índice é melhor (no prepare); Então não crie muitos índices se você executa muitas
atualizações… No Update, não altere colunas que não sofreram alteração, para não demandar tempo
para atualizar o índice ( altere somente o necessário );
3) colunas que são candidatas a índice são aquelas que fazem parte de uma WHERE, ORDEM BY
ou GROUP BY… nem todos devem ser transformados em índices… somente alguns… entenda como
o banco de dados usa as estatística para escolher qual o índice é mais adequado para inclui no plano
de otimização;
4) índice composto ou simples ? depende do banco de dados… no Firebird sempre que testei o
resultado melhor foi obtido em índices simples Ex: create index cadastroNome on
produtos(codigo,nome)….. pode não ser tão eficiente quanto criar 2 índices… analise o resultado
antes de criá-los;
5) os índices são bons se a coluna registrar o maior numero possível de informações diferentes… por
isto o melhor índice é o da chave primária, pois existe somente uma linha possível, nenhuma é igual
a outra. Um índice de FILIAL em uma tabela pode não valer NADA se a empresa tem uma única
loja… o mesmo vale para uma coluna S ou N – resulta em muitas linhas com o mesmo valor;
6) usar funções dentro de WHERE ou GROUP BY deve ser avaliado com cuidado, na dúvida eviteos.
7) não use NOT IN ou <> em uma WHERE, em geral o gerenciador ignora todos os índices nestas
situações… Ex: Errado: select qtde from vendas where data<>’today’ (isto mata o índice)… prefira
Correto: select qtde from vendas where ‘today’ >data and ‘today’ < data (isto vai permitir usar o
índice de data);
8) não tenha preguiça…. não pode fazer “select * from xxxxx” (digite as colunas que vai precisar),
isto vai economizar tempo do servidor e de banda de transmissão dos dados;
9) se a sua tabela tem menos de 1000 linhas…. é provável que nem precise de índice. Mas se ela tem
1 milhão de linhas, não dá para ignorar o índice;
10) evite até a morte em criar uma tabela sem indicar a sua chave primária; Bancos de dados foram
feitos para ter chave primária na mais profundo da sua concepção. De a ele uma chave primária para
que ele fique feliz;
11) sempre que for fazer um SELECT tente minimizar ao máximo o número de registro que ele irá
buscar no banco de dados… Se vai precisa da QTDE vendida e o NOME do produto, não faça 2
SELECTs…. junte os 2 em um único SELECT;
12) se acabou de buscar os dados de um cadastro…. não vai buscar de novo o que já conhece…
guarda na memória e reutiliza a informação que já foi obtida. Por isto o GOOGLE é tão rápido – ele
memoriza tudo e vai no buscar somente dados que ainda não conhece.
13) No FIREBIRD, deixar conexões sem dar commit ou as vezes em aberto sem encerrar
adequadamente pode deixar lento o COLETOR DE LIXO do firebird… então inicie e termine um
processo… de preferência, encerre a conexão – isto vai trazer um benefício muito grande para o
banco de dados….. AFINAL devemos escrever para o banco de dados, só assim ele responderá com
eficiência.
Para fechar, “backup “ você vai precisar um dia… faça testes para saber se ele é confiável – não
deixe para descobrir quando for precisar. Não deixe-o no mesmo disco (de preferência, leve para
casa);