[firebase-br] Plano

[Gladiston Santana]

Quando se coloca um left[outer] join numa query, isto é, observar também os
registro que não atendam a junção, invariavelmente o banco faz um table
scan dos dados e nessa situação, ja que ele leu tudo o que precisava talvez
chegue a conclusão de que não precisa mais do indice.
Entre consultar um indice (uma operação de I/O é considerada cara) e fazer
qualquer sort com dados que já estão em memória, ele talvez prefira a
segunda opção. É a lei do menor custo.
Analisar plans não é fácil, cada banco pode ter sua distinção, mas o que eu
percebo ente 3 bancos que mais trabalhei é que o left[outer] costuma
desprezar os indices. No MSSQL isso é bem obvio porque ele guarda
estatisticas de planos diferentes que já usou para a mesma sentença quando
vocÊ dá o "Prepare" e depois ele fica com a que deu menor tempo e realmente
faz sentido quando ele negocia não usar indice.
O left é um tipo de consulta para ser algo não corriqueiro, as vezes, eu
uso uma coluna com "exists" ou "not exists" para responder "sim" ou "não" e
daí o operador abre o registro para ver os detalhes do que existe ou não
existe. Evitando sempre que possivel operações de left join dentro duma
parte muito repetida do programa.


[]´s

Em ter, 29 de jan de 2019 às 14:30, Maciel Soncini Bueno <
maciel em 2msolutions.com.br> escreveu:

> Boa tarde,
>
> Uma dúvida.
>
> Tenho uma query com inner join.
>
> Os campo em comum é PK em uma tabela e FK na outra, mas mesmo assim, no
> plano de execução, me mostra que nenhum índice foi utilizado.
>
> Os índices estão todos ativos.
>
> O que pode estar ocorrendo?
>
> XLABAGENDA_IDX3), ML1 INDEX (RDB$PRIMARY28)), ML6 INDEX (RDB$PRIMARY61)),
> ML2 INDEX (RDB$PRIMARY35)), ML16 INDEX (RDB$PRIMARY33)), ML3 NATURAL),
> FICHA NATURAL), UNIDADE INDEX (RDB$PRIMARY78))
>
> Adapted Plan
> PLAN JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (*XLAB08000 NATURAL*,
> XLABAGENDA INDEX (FK_XLABAGENDA_1, XLABAGENDA_IDX3), ML1 INDEX
> (INTEG_531)), ML6 INDEX (INTEG_565)), ML2 INDEX (INTEG_538)), ML16 INDEX
> (INTEG_536)), ML3 NATURAL), FICHA NATURAL), UNIDADE INDEX (INTEG_582))
>
> A query segue abaixo:
>
> select xlabagenda.checkin, xlabagenda.atendiment, xlabagenda.paciente,
> ml1.exame, ml3.medico, unidade.descricao as UNIDADE,
> ml2.apelido, ml16.destino, ml6.coleta, xlabagenda.data, xlabagenda.hora,
> xlabagenda.recepcao,
> xlabagenda.confirma, xlabagenda.chegou, xlabagenda.falta,
> xlabagenda.atendido, xlabagenda.codfic, xlabagenda.coddst,
> xlabagenda.codconv, xlabagenda.codcol, xlabagenda.coddst,
> xlabagenda.registro, xlabagenda.codexa, xlabagenda.sexo,
> xlabagenda.matric, xlabagenda.serie, xlabagenda.requer, xlabagenda.matmed,
> xlabagenda.codcid, xlabagenda.idade, xlabagenda.codplano,
> ficha.dt_nasc, xlabagenda.importado, xlabagenda.amostra,
> xlabagenda.codmeds, xlabagenda.senha, xlabagenda.codlivro,
> xlab08000.descricao, XLABAGENDA.URGENTE,
> XLABAGENDA.SENHA_PAINEL, XLABAGENDA.FONE, xlabagenda.codreq,
> XLABAGENDA.PESO, XLABAGENDA.ALTURA, XLABAGENDA.TIPO_CHECKIN, FICHA.CPF,
> ML3.REGISTRO AS CRM
> from xlabagenda
> INNER JOIN ML1 ON ( XLABAGENDA.CODEXA = ML1.CODEXA)
> INNER JOIN XLAB08000 ON (XLABAGENDA.CODLIVRO = XLAB08000.CODLIVRO)
> LEFT OUTER JOIN ML6 ON ( XLABAGENDA.CODCOL = ML6.CODCOL)
> LEFT OUTER JOIN ML2 ON ( XLABAGENDA.CODCONV = ML2.CODCONV)
> LEFT OUTER JOIN ML16 ON ( XLABAGENDA.CODDST = ML16.CODDST)
> LEFT OUTER JOIN ML3 ON ( XLABAGENDA.CODMEDS = ML3.CODMEDS)
> LEFT OUTER JOIN FICHA ON (XLABAGENDA.CODFIC = FICHA.CODFIC)
> LEFT OUTER JOIN UNIDADE ON ( XLABAGENDA.CODUNI = UNIDADE.CODUNI)
> WHERE XLABAGENDA.DATA BETWEEN :DATAI AND :DATAF
>
> A algo que possa fazer para forçar a utilizar o  índice?
>
> Isso não ocorria antes. Fizemos um backup  / restore para a versão mais
> atual do Firebird 2.5 e me parece que agora começou com essas "histórias".
>
>
> Maciel
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>


-- 
A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
na Melhoria Continua.

Em março de2018 migramos com sucesso para a nova versão da ISO 9001.

Somos a única Empresa Brasileira de Engenharia de Laboratórios com
certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
Fabricação e Instalação de Laboratórios.