O que é muitas vezes subestimado por muitos é o desempenho do MySQL em consultas complexas em grandes conjuntos de dados ( ou seja consultas agregadas e grandes) e trabalhos de grupo. Não é raro ver consultas que levavam milissegundos estarem ocupando alguns segundos, em especial em determinadas configurações de um sistema operacional, e em servidores de pequeno porte ( ou seja, ter apenas um drive de disco), mesmo tendo uma consulta, em execução simultaneamente. Vamos falar um pouco sobre isso e como prevenir este acontecimento.


Limpando Cache


Não realizar esta atividade pode deixar seu banco de dados um pouco mais lento, a consulta de crunches em grande quantidade de dados o comando set apaga os dados do seu jogo habitual de trabalho a partir do cache do sistema operacional. Sistemas operacionais e o MySQL empregam várias estratégias para minimização deste efeito, para evitar que isso aconteça.


A fome de disco


A eficiência do cache cai quanto maior for o número de pedidos e acesso ao disco, que por sua vez pode ser 100% ocupado executando as suas consultas de trabalho em lotes. Isto é bastante ruim quando existe somente uma unidade para localização do banco de dados e esta consulta pode manter o sistema sempre ocupado. Como a unidade está sempre ocupada os pedidos são agendados para serem realizados posteriormente.

Você pode imaginar que não existe a necessidade de esperar muito tempo pois não se trata de uma consulta em um disco à parte o que ocorre na verdade, é uma grande quantidade de consultas que ficam empilhadas , reduzindo a eficiência da cache. Em alguns casos os pedidos levam em média na fila mais de 1 segundo, o que se trata de muito tempo quando falamos de um disco IO.


Os problemas de programação


Os horários do OS Disk IO também podem de certa forma auxiliar neste caso. Tentar otimizar o trhoughput antes da latência, ou seja, você deve realizar uma consulta fazendo uma varredura completa nas tabelas ( leituras sequenciais) onde seus pedidos são priorizados , não requerendo a movimentação da cabeça de leitura do disco diferente mente de outras solicitações IO que encontrem-se em locais aleatórios. Alguns programadores com hábitos da velha guarda podem considerar o disco pobre; no Linux 2.4 poderíamos realizar uma consulta e varredura únicas e completas em toda a tabela afim de não tornar as coisas tão más, com um “ls” levaríamos mais de 10 segundos para exibir um diretório com alguns poucos arquivos. Nos últimos tempos kernels Linux ou schedulers CFQ IO estão trabalhando melhor com isso.



O que você pode fazer?


Fazendo relatórios sobre um servidor escravo. Realizar os relatórios sobre um servidor escravo é uma excelente ideia caso você possua um. Mesmo utilizando tabelas InnoDB não sofrendo bloqueios das tabelas e relatórios de consulta, que podem afetar drasticamente o desempenho de seu site. Ao invés de utilizar um disco escravo pode ser realizados backups instantâneos, LVM do banco de dados atual com os mesmos resultados. Em casos especiais o escravo não pode receber todas as informações , como por exemplo carregar os dados ou construir tabelas de resumo. Sendo assim deve-se mover uma parcela da carga para o servidor onde você pode ler dados e escreve-los para o máster ou ainda você pode elaborar tabelas de resumo sobre o escravo e move-las para o máster usando mysqldump ou transferir o arquivo caso estela utilizando tabelas MyISAM .


Use limit nas ações


Caso não tenha a oportunidade de executar o trabalho em um servidor escravo, trabalhando com dados antigos você pode corta a tabela, mas não faça isso com grandes conjuntos de dados. Não pode existir um descuido entre estas operações, caso você exclua coisas usando DELETE.... LIMIT 1000 e por um descuido inserir um 10 no meio. Espalhando a carga desta forma você utilizou grande parte do cache e não serão eliminados de uma só vez, algumas consultas podem ir se acumulando por que a consulta levou bastante tempo e recursos, estes terão tempo para solucionar esta na próxima ocorrência da consulta.


O Tempo


Isso é meio obvio mais devemos mencionar caso exista a necessidade de realizar algo mais intenso consumindo menor carga. Não basta apenas colocar a tarefa agendada para 04:00 e esquece-la, caso não realize as atividades agendadas isso pode ser muito ruim para os usuários do site, certifique-se que a carga operacional está baixa o suficiente para realizar a sua consulta complexa ou trabalho em lote para não retardar o bom funcionamento e gerar grandes confusões. Em alguns ambientes que operam 24/7 isso é uma grande solução pois ninguém irá sofrer em determinados momentos.

Traduzido de: www.mysqlperformanceblog.com