[firebase-br] Como interpretar isto?

[Douglas Tosi]

2009/1/27 Tiago <tijgrillo em gmail.com>:
> Plan
> PLAN JOIN (II INDEX (FK_MOVCLII_CADPRO_CODPRO),CC INDEX
> (MOVCLIC1),CADFISC INDEX (CADFISC1))
> PLAN JOIN (II INDEX (FK_MOVCLII_CADPRO_CODPRO),CC INDEX
> (MOVCLIC1),CADFISC INDEX (CADFISC1))
> PLAN JOIN (II INDEX (FK_MOVCLII_CADPRO_CODPRO),CC INDEX
> (MOVCLIC1),CADFISC INDEX (CADFISC1))
> PLAN SORT (SORT (JOIN (CADFISC NATURAL,MOVCLIC INDEX
> (FK_MOVCLIC_3,MOVCLIC_IDX2),MOVCLII INDEX (FK_MOVCLII),CADPRO INDEX
> (CADPRO1),CADFAM INDEX (PK_CADFAM),CADGRU INDEX (CADGRU1))))

Este plano inteiro é um sql só com vários subselects?
É muito grande pra dizer o que pode estar errado. Ajudaria muito ter o
sql, a seletividade dos índices envolvidos e o número de registros nas
tabelas onde está sendo feito table scan (cadfisc).
fwiw, eu sempre analiso o sql antes. Se não tiver nada de obviamente
errado com ele, aí sim vou pra análise do plano, que é mais complexa e
toma mais tempo.

> Por causa destes dois SORT ai? talvez fosse melhor eu alterar para um
> NATURAL, é isto?

Quase.
Os dois sort podem sim ser problema. Mas é só um "pode". Tem que
analisar melhor.
O que também pode deixar bem lento é a ordem de execução de subselects.

Até onde lembro, são 3 maneiras de se ler uma tabela:
- natural: é o table scan sem ordem nenhuma. A tabela será lida
completamente na ordem em que for encontrada.
- order: é quase um table scan. Só que os registros são lidos segundo
a ordem de um índice específico.
- index: quando se usa um índice para filtrar a tabela.

O sort é uma outra operação. Não está diretamente ligada as três
acima. O sort é aplicado quando o otimizador precisa ordenar um
conjunto de linhas e não tem nenhum índice disponível para isso.
O sort não tem relação com natural. O que você poderia ver no lugar do
sort é um order.

Está meio abstrato demais isso né? Estou com dificuldades em explicar.
Manda os detalhes do sql, fica mais fácil.

hth,
-- 
Douglas Tosi
www.sinatica.com