Firebird e seus PLANos de otimização

Se fossemos enumerar as qualidades do Firebird, poderíamos citar : flexibilidade, simplicidade e portabilidade.
No entanto, quando falamos de Servidores SQL, existem muitas outras características que marcam sua excelência.
Por exemplo, um produto pode ser simples, flexível e portável, mas e se a performance não for boa ?
Voce usuaria ele mesmo assim ?

Acrescentou-se a minha querie um tal PLAN (TABELA_CLIENTES NATURAL), como eu havia dito antes, ou seja, o otimizador escolheu não fazer nenhuma seleção de índice.

Para ver o tempo que essa query levou para ser executada clique na orelha "Estatistics":

Interessante, não ?
Levou nem 1 milisegundo para pesquisar em 7.091 registros, e se tivesse usado qualquer outro indice teria demorado mais.

5- Vamos criar uma nova querie, dessa vez uma que faça o Firebird usar o "otimizador de querie".
Crie a seguinte querie :
SELECT * FROM TABELA_CLIENTES WHERE razao_social LIKE "INDUSTRIA%MOVEIS%"
Poderá usar qualquer outro campo, contando que tambem possua um índice associado.
Execute a querie.
6- Selecione a orelha "Plan", e observe que dessa vez ele usou um PLAN :

Naturalmente, usou um PLAN que utilizasse um índice associado a razão social.

E observe então as estatisticas :

Como essa tabela de clientes possui apenas 7.091 registros a performance não aumentou tanto assim, foi apenas de 10% !
Mas a performance num ambiente cliente/servidor é linear, isto quer dizer em outras palavras, que se o Firebird leva menos de 1 segundo para encontrar um registro numa base com 10.000 registros, a probabilidade de que com uma base 10 vezes maior, digamos 100.000 registros, o tempo nunca será de 10segundos, provavelmente continuará a levar o mesmo 1 segundo.
Não é como nos bancos de dados desktop em que a medida que aumentamos dez vezes nossos dados, perdemos uma performance de 15 vezes ou mais.

Um dado interessante no Firebird é que essa estatistica eu retirei num banco de dados em produção e passados mais ou menos 15 minutos, fui até o Firebird e re-executei a mesma querie anterior e note o seguinte :

A performance aumentou ainda mais, por que ?
Note que ele não fez nenhuma leitura, isto é, Reads=0, isto quer dizer que quando o Firebird repete um PLAN já executado anteriormente, ele vai buscar os dados em cache, e provavelmente o tempo que levou para buscar os dados foi o tempo de transferencia da memoria do servidor.
Em outras palavras, 00:00:00.0113 foi o tempo mínimo possivel para executar o PLAN.
Aonde eu quero chegar ?

Vamos executar a mesma querie, porém mudemos a clausula LIKE :
SELECT * FROM TABELA_CLIENTES WHERE razao_social LIKE "INDUSTRIA%" (note que retiramos a palavra "MOVEIS").
Com a modificação dessa dessa querie, um número ainda maior de registros aparecerá e a performance diminuirá em relação a execução anterior, certo ? Então executemos a querie acima e vejamos novamente as estatísticas :

Note que ao invés da performance diminuir, ela aumentou ?
Alguem poderia explicar o milagre, como é que eu aumento a quantidade de registros numa seleção de querie e a minha performance aumenta ao invés de diminuir ? Isso tem a ver com a tal performance linear ?
A resposta a essa pergunta é : Veja a quantidade de leitura física, notou ?
"Reads=0", isto quer dizer que não houve leitura física no disco. Provavelmente na execução anterior, o Firebird trouxe muitos registros para a memória além do que nós necessitavamos, em qualquer RDBMS a leitura é por páginas e provavelmente todas as páginas que satisfizeram a nova condição LIKE já estava em cache e disponível para toda a rede. Se outro usuário na rede precisasse de algum registro já pesquisado por mim, usando o mesmo PLAN que eu, é provavel que para esse usuário o Reads seria igual a zero novamente.
Numa rede com muitos usuários simultanêos, essa performance aumenta e vai muito além do que os outros banco de dados desktop (dbf, access, paradox,...) poderiam nos dar.
Claro que isso não é linear a vida toda, como toda a estatística matemática haverá um tempo que essa curva linear tenderá a descer, e quando isso ocorrer então já estará na hora de fazer um UPGRADE no servidor.

Considerações Finais

Percebeu como a "otimização de query" e os "PLAN" são importantes ?
Agora voce iniciante no mundo SQL, poderá perceber o que realmente faz diferença na performance num banco de dados SQL Cliente/Servidor versus aplicações Desktop (Paradox, Access, DBF,...).
É por causa de recursos como este que banco de dados como Oracle, Sybase, MSSQL dentre outros custam tão caro.
No entato, agora voce tem os mesmos recursos usando o Firebird que não lhe custa *nada*.

Links úteis :

Infelizmente a maior parte deste artigo foi produzido com mensagens coletadas em newsgroups, sites na internet, etc... e não num artigo anteriormente escrito, embora certamente exista tais artigos falando exatamente sobre o mesmo tema. Para voce ter acesso a maior parte de assuntos relacionados ao tema, faça o seguinte, vá até o site de buscas www.google.com e procure pela chave "database interbase optimize plan". Muitos links poderão ser consultados.

Este artigo está sob forma de licença GPL (General Public License) e pode ser reproduzido e distribuido livremente em outros tipos de mídia diferentes donde este artigo foi originalmente publicado, no entanto, atente-se para fato de que qualquer produto associado à este artigo também herdará as características GPL e também deverá ser fornecido livremente.
Para maiores esclarecimentos leia sobre a GPL em :
http://www.gnu.org/philosophy/philosophy.pt.html