[firebase-br] Interbase rápido x Firebird muito lento. Me ajudem com esse problema por favor.

[Douglas Tosi]

2009/5/13 Sandro Souza <escovadordebits em gmail.com>:
> Concordo contigo Douglas, mas pior mesmo é ter que percorrer todos os
> registros da tabela de pagamentos por não utilizar índice algum.
> Não acha que isso, por si só, já é a justificativa de criação desse índice?

Não. :)
Por exemplo, um índice com seletividade 0,5. Significa que só tem dois
valores diferentes neste índice.

Caso 1, usando este índice:
Parece ser o Pró: O índice permite filtrar metade dos registro
(supondo distribuição equilibrada dos dois valores).
Contra: Os registros filtrados podem estar espalhados em todas as
páginas daquela tabela. Como a unidade de leitura é uma página e não
uma tabela, não dá pra garantir que apenas metade das páginas vão ser
lidas. Metade dos registros sim, das páginas não.
Contra: A tabela vai ser lida na ordem do índice. Isto provavelmente
vai causar mais leitura aleatórias, o que vai tornar a leitura mais
lenta. (A não ser que a base esteja em um ssd).
Contra: Inserir nesta tabela vai ficar mais lento.
Contra: A metade filtrada desta tabela vai parar no cache, tornando o
cache "sujo" com muitas páginas inúteis.

Caso 2, usando natural:
- A tabela será lida na íntegra, em sequencia. A leitura sequencial da
tabela inteira pode ser mais rápida que a leitura de metade da tabela
de forma aleatória.
- Leituras "naturais" não vão para o cache, exceto se o cache tiver
espaço livre.

Se você fizer um select simples que exige leitura completa:
select count(*) from tabela where campo=1
pode até ser que um índice com seletividade 0,5 ajude. Mas esse é um
caso simplista.
Quando se fizer joins e misturar filtros, o índice ou fica inútil ou
começa a atrapalhar.

Ressalva:
Já vi índices em campos booleano (0 ou 1), onde 99,9% dos valores eram
0 e a única pesquisa feita no campo era procurando os valores 1. Ou
seja, o índice era usado para filtrar 0,01% dos registros. Muito útil.
O índice só tinha baixa seletividade porque o firebird não leva em
conta a distribuição de valores.
Lembro que no FDD ano passado falei isso com o Dmitry Yemanov e ele
acenou com a possibilidade de ter no fb 3. Vamos ver. Acho que chamam
isso de "histograma de distribuição de valores". Me corrijam aqui se
não for.

Concordo com o Eduardo. CodigoAssociado+Ano (nesta ordem) pode ser interessante.

hth,
-- 
Douglas Tosi
www.sinatica.com