30 Updates ao mesmo tempo

[Scientist 2]

Boa noite, preciso atualizar 30 registros ao mesmo tempo, cada um com um valor diferente, ex:

 

update opcao_enquete set opcao = 'vermelho' where cod_opcao_enquete = 1;
update opcao_enquete set opcao = 'azul' where cod_opcao_enquete = 2;
update opcao_enquete set opcao = 'branco' where cod_opcao_enquete = 3;
update opcao_enquete set opcao = 'prata' where cod_opcao_enquete = 4;
...
e mais 26 updates

 

Só que quando eu faço isso, pelo fato de demorar muito da um erro "Execution Max time 30sec", eu sei que o tempo de execução deste DML execede 30 segundos por isso este erro, porém gostaria de saber se tem algum forma mais prática e rápida de executar isso ? (igual o oINSERT que da para fazer vários inserts na mesma execução)

[FernandoPhP 9]

verifica se os campos envolvidos no UPDATE estão indexados. Isso pode melhor bastante o desempenho das consultas.

[Scientist 2]

Como faço para indexar um campo?

[Scientist 2]

Procurei sobre a indexação de campos porém eles servem mais quando há muitos registros, e esse não é o nosso caso. Estou tentando fazer 30 UPDATES, ou seja, 1 update para cada registro.

[giesta 29]

tente:

 

alter table opcao_enquete add index (cod_opcao_enquete)

 

e depois execute os 30 updates.

[Scientist 2]

mais pelo fato de este campo ser uma chave primaria ele já não tem um index associado à ele?

[Motta 645]

Não faz sentido um BD "abrir o bico" com 30 updates.

Não conheço MySql mas tem "boi na linha".

[Scientist 2]

Desculpa mais não entendi "pacas" do que você falou ahah

[Motta 645]

1) Um Banco de Dados não deveria apresentar um problema como este (erro em 30 updates).

2) Não me parece problema de indice , ao menos que as tabelas que se refiram a esta tenham condições do tipo ON DELETE CASCADE que forçariam leituras, e nem seria o caso pois é INSERT.

3) Deve haver alguma configuração de BD (não sei qual) que define um tempo muito baixo para a execução das instruções (Execution Max time).

 

Eu fiz esta pesquisa no Google, veja se ajuda.

[Scientist 2]

Vamos lá ...

O erro ocorreu como eu disse não pelo banco mais sim pelo PHP, que dizia que o tempo de execução máxima deveria ser de 30 segundos,aumentei este tempo para 60 segundos no php.ini e tudo ficou normal.

 

O problema é que achei lento 30 updates demorarem mais de 30 segundos e gostaria que vocês pudessem me ajudar a melhorar o desempenho disso.

[Motta 645]

Isto pode depender da máquina , SO, concorrência com outras aplicações, acesso à disco, ou seja um caminhão de coisas.

 

Mas sua estranheza é correta.

Tem alguma trigger ligada a esta tabela ?

[Scientist 2]

Tenho um palpite:

 

estou desenvolvendo o sistema localmente conectado a um banco remoto. Quando o sistema tiver pronto vou migrá-lo para o mesmo local que fica o banco, ou seja, o sistema e o banco vão estar na mesma maquina (localmente conectados) e ficará mais rápido.

 

me corrija se estiver errado !! hehe

[Motta 645]

Está certo.

[Scientist 2]

Então é isso mesmo.. obrigado ! heheh

[Caio Cardoso 0]

Amigo,

bom dia.

 

Ao invez de fazer 30 updates,

faça apenas 1 utilizando a função CASE WHEN

 

O problema dos 30 updates é que você está vasculhando a tabela 30 vezes,

ou seja, se você tem 1 milhão de registros na tabela,

com estes updates você tem 30 milhoes de verificações, para corrigir isto utilize o CASE,

você faz apenas 1 update e trata todas as condições de uma unica vez.

 

 

Tente o seguinte:

update opcao_enquete

set opcao =

CASE COD_OPCAO_ENQUETE

WHEN 1 THEN "AZUL"

WHEN 2 THEN "VERMELHO"

WHEN 3 THEN "VERDE"

.....

WHEN 30 THEN "AMARELO AZULADO COM BOLINHAS VERMELHAS"

END

 

 

Creio que isto sim vai reduzir drasticamente o tempo de execução.

 

No post de cima dei uma possivel solução para o seu problema,

 

agora segue comentário spbre a sua observação de deixar a aplicação no mesmo servidor do BD:

 

você migrando a aplicação para que desta forma o processamento seja local não irá mudar em nada a quantidade de recursos utilizado, a unica diferença está na utilizado da banda da rede, que nao será mais necessária.

 

- Invista em indices, nunca em excesso, procure cria-los apenas com os campos que realmente usa na condição WHERE, o SQL possui o EXCUTION PLAN, nao sei se o MySQL possui algo parecido.

- Evite o select * from trazendo realmente o que é extremamente necessário

- Nos JOIN deixe sempre a tabela menor do lado esquerdo

 

São dicas modestas mas que podem fazer uma grande diferença.

 

Outra coisa tente manter uma boa qualidade nos dados para evitar a utilização de funcoes para tratamento de dados,

eu sofro muito com isso aqui, o que acaba gerando processamento desnecessário já que isto poderia ser tratado na aplicação com a utilização de algumas mascaras.