Otimização de query!

[CleitonHanzenParticipante]

[quote=”ramasine”:3ov3ew5a]Tenho essa query!

SELECT terper.out_num_ter, ter.out_nome, terper.per_codigo, per_descricao
FROM fin_perfil per, fin_out_ter ter, fin_out_ter_per terper
WHERE terper.out_num_ter = ter.out_num_ter
AND terper.per_codigo = per.per_codigo
ORDER BY 1, 3

Plano

Plan
SELECT STATEMENT CHOOSECost: 646 Bytes: 2 575 172 Cardinality: 27 991
6 SORT ORDER BY Cost: 646 Bytes: 2 575 172 Cardinality: 27 991
5 HASH JOIN Cost: 60 Bytes: 2 575 172 Cardinality: 27 991
3 HASH JOIN Cost: 15 Bytes: 711 227 Cardinality: 17 347
1 TABLE ACCESS FULL FIN.FIN_PERFIL Cost: 3 Bytes: 2 706 Cardinality: 82
2 INDEX FULL SCAN UNIQUE FIN.OTP_PK Cost: 48 Bytes: 138 776 Cardinality: 17 347
4 TABLE ACCESS FULL FIN.FIN_OUT_TER Cost: 40 Bytes: 804 015 Cardinality: 15 765

Se eu utilizar o select para obter os dados, em vez de ter o inner join às tabelas que contem os dados, o custo do otimizador é muito superior! Existem índices que ligam estas tabelas, porque que mesmo assim está sendo feito um full table scan em ambas as tabelas?[/quote]

Opá…

Desculpe a intromissão, mas com optimizer=choose, all_rows ou first_rows (baseado em custos/estatísticas), nem sempre a existência de índice fará o otimizador utilizar este índice e isso pode ocorrer por vários motivos q vão desde a distribuição das chaves (cardinalidade muito elevada, e o otimizador considera menos “custo” fazer Full table scan) até índices fragmentados…

Mas outro detalhe que observei na tua query, é que todos os registros das tabelas envolvidas vão ter que ser lidos, pois não está sendo passada restrição nenhuma (somente está sendo feita a comparação entre as tabelas, mas não existe uma cláusula restritiva “where campo=100” por exemplo)….

Indepente do custo que a query está gerando, iria fazer um teste de deixá-las rodando e iria cronometrar o tempo, às vezes o Full table scan pode ser mais custoso mas retorna mais rápido os registros…. 😉