Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Da configuração para Performance Tuning de um banco de dados em MySQL com objetivo de otimizar o desempenho deste Banco de Dados. Este artigo é o primeiro de uma séria sobre Performance Tuning em MySQL.
Para que serve?
Para configurar o MySQL corretamente para que ele utilize de forma otimizada o máximo de recursos possíveis do ambiente computacional onde está instalado.
Em que situação o tema é útil?
Em casos onde o poder de processamento são características fundamentais do ambiente.
Como todos sabem, a Oracle comprou a Sun, que por sua vez, anteriormente havia comprado a MySQL AB (Nota DevMan 1), empresa criadora do Banco de Dados MySQL.
MySQL AB (fundada em 1995 e adquirida pela Sun Microsystems em 2008) foi a empresa responsável pela criação do MySQL assim como de produtos tais como MySQL Cluster. A empresa está dualmente sediada em Uppsala, na Suécia, e em Cupertino, nos Estados Unidos, com escritórios em outros países (Paris, França; Munique, Alemanha; Dublin, Irlanda; Milão, Itália; e Tóquio, Japão).
Com cerca de 400 funcionários em 25 países, a MySQL AB foi uma das maiores empresas de open source do mundo. Cerca de 70% dos empregados trabalhavam para o MySQL a partir de suas casas.
Eu não tive, e continuo não tendo dúvidas de que a Oracle irá investir cada vez mais no MySQL, pois creio que, para a Oracle Corporation, ele não é um competidor direto dos Bancos de Dados Oracle: ele é um competidor direto do SQL Server e do PostgreSQL. Não quero dizer aqui que um Banco de Dados é melhor do que outro, acredito que cada um tem seu campo de uso. Portanto, espero ver mais alguns anúncios da Oracle a respeito de melhorias de escalabilidade do MySQL, especialmente em ambientes Windows Server, muito em breve.
Confirmando minhas suspeitas, há alguns meses a Oracle anunciou, na própria MySQL Conf, melhorias de escalabilidade no MySQL, adotando a árvore 5.5 como a sucessora da 5.1 - descartando a 5.4 (que foi iniciada pela Sun) e 6.0 (que foi iniciada antes da 5.4, pela MySQL AB), pelo menos por enquanto. Mesmo descartando as versões anteriores, as funcionalidades criadas nestas versões foram incorporadas à versão 5.5, hoje em estágio Beta.
Mesmo com as melhorias de escalabilidade apresentadas nos Benchmarks, o MySQL não tem um bom desempenho com a configuração padrão. Além disso, é um dos Bancos de Dados mais sensíveis a parâmetros do mercado, fazendo com que uma pequena alteração no arquivo de inicialização traga um grande benefício, ou cause um grande desastre na aplicação. Para complicar ainda mais, o MySQL não é propriamente um SGBD, mas um encapsulador de Engines de SGBDs, como o MyISAM e InnoDB, que já vem habilitados por padrão. A propósito, a Innobase, mantenedora do Engine InnoDB (o mais utilizado em Bancos de Dados MySQL) já fora comprada pela Oracle antes mesmo da compra da MySQL AB pela Sun.
O MySQL é um banco de dados perigoso para os DBAs dentro das empresas. Isto porque muitas vezes estes bancos de dados aparecem como suporte a alguma aplicação específica, criada para resolver algum problema pontual (por exemplo, gerar um relatório executivo) sem contato com a área de TI (e os DBAs), até que ele se torne um sistema importante demais e, subitamente, passe a ser de responsabilidade da equipe de infraestrutura. Quando chega a este ponto, geralmente ele já está com problemas de desempenho, e sem uma estrutura de Backup ou sem uma estratégia de Disaster Recovery (“Recuperação de Desastre”). Adicionalmente, são raros os bons Treinamentos Avançados em MySQL para DBAs, e muitos DBAs com experiência de outros bancos de dados tendem a negligenciar estes aspectos do MySQL, por achar que ele é um SGBD fácil.
Mas como já explicamos, a arquitetura de encapsulamento de Engines do MySQL o torna um dos mais complexos do mercado, principalmente para ...
