Processamento do banco MySq"

[Luiz Fernando]

Pessoal já faz 7 anos que utilizo este banco de dados, durante este período com a ajuda do pessoal aqui fui customizando as rotinas que levava muito tempo para processar, tudo que demorava foi resolvido, mais as vezes numa rede de 30 terminais, um usuario por engano manda imprimir um relatorio com informações de 3 anos por exemplo, dai me trava a rede toda, sera que existe alguma forma de contornar isto.

 

Obg 

[Luiz Fernando]

 

esse relatorio vc usa select(sql) ou comando xbase?

Colega o projeto todo só uso comandos nativos SQL, nada de xbase.

[Jorge Andrade]

Luiz, vc tem que analisar seu código, instrução sql pra saber se ele está fazendo varreduras demoradas e várias vezes para a mesma coisa, exemplo:

 

Vc entra num restaurante e o garçom te entrega o cardápio.

1 - Vc pede uma cerveja e o garçom não te ofereceu uma opção e não te perguntou e nem anotou qual item do cardápio vc escolheu

2 - Pede outra cerveja e o garçom de novo,  não te ofereceu uma opção e não te perguntou e nem anotou qual item do cardápio vc escolheu

3 - Pede outra cerveja e já está bêbado e nem sabe o que vai comer, e o garçom não te ofereceu uma opção e não te perguntou e nem anotou qual item do cardápio vc escolheu

4 - Vc chama o garçom e escolhe o item do cardápio, ele avisa que vai demorar x tempo.

Resumo, se ele te perguntasse em uma das vezes que vc pediu a cerveja ou te oferecesse uma opção do cardápio e vc escolhesse, com certeza já iria mensurar o tempo que a sua refeição iria demorar e vc saberia qto tempo demoraria pra tomar a última cerveja, combinando o tempo da chegada da refeição, além do tempo dele no atendimento.

É um exemplo xulo, mas a intenção é tentar combinar o máximo de solicitações ao BD em uma única instrução de forma que as primeiras cláusulas satisfaçam de forma integral e demais necessidades, cláusulas independentes, porém derivadas das anteriores.

Uma outra coisa. Pode ser a instrução combinada com a impressão, não esteja indo pro Spool, liberando a rotina e as tabelas envolvidas no processamento.

Se falei asneiras, desconsidere e me desculpe.

 

 

[]s,

[miragerr]

Ola, Bom dia

 

Vou dar um pitaco, instruções de SELECT não travam o Mysql para outros SELECTs, o que pode travar é alguma instrução de UPDATE ou INSERT em algum FOR...NEXT com muitos registros, isso faz com que a TABELA em questão fique bloqueando a cada INSERT, isso acontece comigo quando vou atualizar produtos em filiais.

 

Espero ter ajudado.

[evandro]

Olá,

Pela primeira vez vou discordar do Jackson. Dependendo do SELECT trava tudo. Principalmente se tiver SUBSELECT. Veja também os índices. Apesar de não esclarecer muito mas use o EXPLAIN.

[miragerr]

Ola, Bom dia Velinho

 

Amigo, tenho alguns SELECTs cabeludos, e longos, mas lhe garanto, não tenho problemas de travamento, como falei acima, acontece quando tenho um LOOP com muitos registros de INSERT e UPDATE, isso tem me atrapalhado um pouco, e olha que tenho um cliente com mais de 60 PCs vendendo ao mesmo tempo.

Uma coisa que vou colocar em pratica são VIEWs, pois gera uma tabela já pronta para a necessidade que pretendo, e fica muito prática, pois voce só faz o SELECT na VIEW e pronto.

Espero ter ajudado

[evandro]

Olá,

Pô, elogio o cara dizendo que ele sabe tudo e só agora vou discordar e ele vem com "Ola, Bom dia Velinho".  Nem vou falar nada!  Hehehehe

Mas dependendo dos joins e falta de índices aliados a um subselect, já vi muito servidor parar. Tiveram de reiniciar o serviço. 

[miragerr]

Ola... Bom dia velinho

 

É elogio sim o "VELHINHO" pois garanto que você já participou de muitos cortejos de amigos seus, e você ainda esta por aqui, desfrutando, ou estou errado , então você é um privilegiado.

Quanto as SELECTs com muitos JOINs até concordo, sem uma boa estruturação, realmente pode ficar lento, mais travar o SELECT de outros, acho pouco provável... o que faz travar um SELECTs ou o BANCO DE DADOS é um UPDATE ou INSERT que esta aguardando a liberação da TABELA e outros SELECTs estejam fazendo uso da TABELA em questão com o INSERT.

 

O que ele pode fazer é o seguinte usando um FRONT-END:

SELECT * FROM information_schema.processlist WHERE INFO is not null;

 

E analisar qual é o PC ou processo no MYSQL que esta fazendo o BLOQUEIO, pois a informação apare no SELECT acima, pois eu já usei muito o comando acima para encontrar quem é o PC que esta fazendo o travamento, como também o que esta ocasionando o TRAVAMENTO.

 

Espero ter ajudado.

[Luiz Fernando]

Pessoal obg pelas dicas acima, aqui uso muito subselect, o desempenho usando eles é coisa fantástica, meus insert hoje é tudo em massa, por exemplo, se tenho um pedido com 80 itens por exemplo, faço um único insert(quem me ajudou isto na época foi o Evandro)  , qdo digo travar, estou falando coisa de 50 segundos a 1 minuto, não é a ponto de reeniciar o serviço do mysql, o duro que num PDV 50 segundos é uma eternidade, relatorios , rotinas do dia a dia, fui dando tratamento nas rotinas, sugestão de compra por exemplo, de 6 minutos passei para 2 e depois com novos ajustes para 5 segundos, tudo tem como dar jeito, o duro qdo fazem coisas fora da rotina.

 

Obg

[joaosolution]

Srs.

Boa tarde

Quando o volume de dados é grande para ser filtrado, vai depender do processador do servidor, nem sempre vai depender do Select que estamos executando.

Claro que ter índices e verificar os left join da consulta são importantes, mas tenho caso igual ao relatado pelo colega.

O mesmo relatório mensal dia 01 até dia 31 (ou 30 ou 28) é rápido. Mas o mesmo relatório para o ano 01/01 a 31/12 o processamento é totalmente diferente, o volume de dados é diferente e o tempo de execução também.

Para esses casos avalio com o cliente a necessidade do relatório e crio uma situação a parte com uma view por exemplo. E normalmente não deixo gerar o relatório com períodos muito longos, coloco avisos na tela do usuário. Pois mesmo que seja só SELECT trava o servidor.

Att

João Bosco

 

[Luiz Fernando]

Dois colegas citou o view, pelo que pesquisei ele cria um espelho de um select no banco de dados, mais no que isto pode ajudar ? realmente não entendi aonde está a vantagem de se usar ele.

[joaosolution]

Luiz

Bom dia

A view é o resultado de um select já processado no banco de dados, ela fica armazenada no cache do mysql permitindo um acesso mais rápido.

Att

João Bosco

[Luiz Fernando]

 

Luiz

Bom dia

A view é o resultado de um select já processado no banco de dados, ela fica armazenada no cache do mysql permitindo um acesso mais rápido.

Att

João Bosco

Colega vc utiliza este recurso ai, realmente melhora em algo, pelo que pesquisei não consegui entender aonde esta a vantagem.

Obg

[alex2002]

Olá.

View não vai melhorar performance de forma alguma, pelo contrário pode até atrapalhar. O que vai resolver definitivamente o seu problema é colocar índices apropriados para este select. Inclusive usando o explain conforme o Evandro indicou vc consegue ver quais os índices serão utilizados e com isso ir otimizando o mesmo até obter uma performance legal.

Quanto às views elas jamais podem ser utilizadas em tabelas grandes (aprendi isso com nada mais nada menos com o Wagner Bianchi) porque toda vez que você der um select em uma view ela simplesmente vai executar o select secundário a qual você criou a view. Eu utilizo views em tabelas que não são muito extensas, para compor dados em uma determinada situação, mas em tabelas de movimentos jamais (a menos que tenham um índice específico pra isso).

 

[vailtom]

Importante averiguar o resultado do EXPLAIN, algumas vezes o banco requer algumas optimizações pra operar de um modo melhor dependendo do hardware onde ele está sendo executado.

[ADutheil]

Voltando a pergunta inicial: "um usuário por engano manda imprimir um relatório com informações de 3 anos". O problema parece ser de BIOS não de BD. Se o usuário manda imprimir um relatório que envolve milhões de registros vai demorar. O relatório deve ter uma tela de seleção com data inicial e final ou algo parecido. Eu colocaria um alerta de confirmação quando o intervalo fosse superior a determinado tempo. 

[joaosolution]

Bom dia

No meu caso eu trato o período para quebrar mensal:

Ex.:

Se a pessoa pede de Janeiro a Dezembro eu divido em 12 Selects diferentes, coloco uma barra de evolução mostrando 1/12,2/12,3/12.4/12, etc

Desta forma o usuário não pensa que o relatório está travado.

Quando o relatório era um select de 12 meses o tempo de processamento no servidor era maior e a tela ficava parada, o BIOS falava que havia travado o relatório, mas o problema era o tempo de resposta do servidor.

Att

João Bosco

[ADutheil]

Esta história de relatório de janeiro a dezembro me lembrou de meu primeiro sistema em dBase II que rodava num COBRA 210 em 1984/5. No início de janeiro rodava o fechamento do ano anterior e o processamento com a impressão levava ... espere um pouco ... porque a pressa? ... uma semana. O bicho tinha 2 disquetes de 8 polegadas. 1 para o SO e o outro para os dados. Era uma tal de chacoalhar, clic clac clic clac, acessa um drive acessa outro e depois de alguns minutos gravava uma linha na impressora. Digo gravava porque pela zoada parecia que estava gravando mesmo. 

Parece muito tempo para gerar um relatório mas na época foi uma pequena revolução. Antes quando era feito manualmente os resultados saiam em março.