Melhorar performance de select em DB2

6 respostas
coca1na

Galera, seguinte, possuo uma tabela que contém milhares de registros, e a previsão é que chegue a milhões… bom… hj, o usuário realiza uma busca parametrizando algumas informações via aplicação, por meio do hibernate, é realizada uma busca no banco de dados (DB2), porém a consulta não está retornando, pois está dando timeout…

veja bem, a idéia não é aumentar o tempo do timeout, mas sim automatizar a query para retorno dos dados.

a query é mais ou menos assim:

select distinct tabela10.dado1,
tabela9.dado2,
tabela1.dado3,
tabela4.dado4,
tabela3.dado5,
tabela6.dado6,
tabela1.dado7,
tabela1.dado8
from 
schema1.tabela1,
schema1.tabela2,
schema2.tabela3,
schema2.tabela4,
schema2.tabela5,
schema2.tabela6,
schema2.tabela7,
schema2.tabela8,
schema2.tabela9,
schema2.tabela10
where
tabela6.dado9 = tabela2.dado9
and tabela1.dado10 = tabela2.dado10
and tabela3.dado11 = tabela1.dado11
and tabela4.dado12 = tabela2.dado12
and tabela5.dado13 = tabela7.dado13
and tabela5.dado14 = tabela7.dado14
and tabela8.dado11 = tabela1.dado11
and tabela9.dado15 = tabela8.dado15
and tabela10.dado16 = tabela1.dado16
and tabela4.dado14 = Parametro1
and lower(tabela6.dado17) like lower('%Parametro2%')
and lower(tabela1.dado18) = lower('Parametro3')
order by tabela10.dado1

Então… pensei em colocar pra query buscar so os 100 primeiros registros por exemplo, mas teria problemas quando o usuário quisesse ver mais de 100… o que é o normal… existe alguma forma da query buscar 100, apresentar na aplicação e continuar buscando e apresentando conforme for necessário ? (por demanda…)

Pensei também, em utilizar INDEX… mas não conheço a utilização de INDEX… logo não sei se seria um benefício ou malefício…

Essa tabela é constantemente utilizada em buscas, inserts e deletes…

Bom… qualquer ajuda será bem vinda…

6 Respostas

jose.jesus

Por que você não utilizou inner join??

leonardobhbr

Se quiser fazer o estilo de paginação vc tera q carregar os 100 registro ordenado pelo maior codigo por exemplo descobrir qual foi o ultimo codigo que o hibernate trousse ai fazer um select de mais 100 registros q o codigo seja a partir do informado

jose.jesus

Uma boa pratica seria você colocar index em todas fks.

mjohnatha

Você antes deveria melhorar o seu select…
Essas 10 junções são realmente necessárias?
Só use DISTINCT em casos que ele REALMENTE seja necessário.
O DISTINCT é pesado, principalmente para grandes quantidades de dados.
Trabalho com DB2 também, chegando a usar tabelas que têm 40, 60, 80 milhões de registros…
Aqui trabalhamos com um limite de 600 registros por consulta o que, de acordo com estatísticas internas, não perde em performance e retorna uma quantidade “satisfatória” para o usuário.

Resta a você avaliar o seu select e tentar achar um valor de registros retornados que seja satisfatório ao seu cliente.

Espero ter ajudado.

leonardobhbr

Falou uma verdade, poucas pessoas fazem ou sabem ou fazem sempre que criar uma chave estrangeira e ela for utilizada pra Select criar um indice tambem pois o indice que vai melhorar o desempenho da consulta nao a FK.

Outra coisa se esta usando hibernate nao da pra usar fetch=Lazy ?

coca1na

Pessoal, muito obrigado pelas rápidas respostas !

O problema foi mais uma questão de enxergar um erro… pois a pessoa que desenvolveu essa parte do sistema cometeu um erro em outro select realizado antes desse, e eu acabei não enxergando o erro durante o dia inteiro de ontem que passei tentando resolver…

Mas hoje eu consegui enxergar e resolveu…

quanto aos questionamentos de vocês, não há necessidade de utilização de inner join.
havia uma junção desnecessária que eu retirei.
e não houve necessidade de utilização de index.

novamente, obrigado a todos!

Criado 20 de janeiro de 2011
Ultima resposta 20 de jan. de 2011
Respostas 6
Participantes 4