Melhorar performance de select em DB2

6 respostas
C

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

J

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

L

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

J

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

M

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.

L

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 ?

C

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