O MySQL Server executará apenas cada consulta em um único thread de primeiro plano , não há suporte para execução multi-thread no lado do SQL. Ele também executa operações de manutenção como ALTER TABLEs que podem reconstruir uma tabela inteira em um único thread.

No entanto, mecanismos como o InnoDB , especialmente em versões recentes, são capazes de executar seus threads de segundo plano simultaneamente , o que significa que certas operações de E/S, como descarga de dados, pré-cache e limpeza de dados, podem ocorrer simultaneamente, com alguns benchmarks de "laboratório" de fornecedores do MySQL mostrando que ele pode escale até 64 núcleos sob alto estresse.

Dito isso, entenda que, na maioria dos casos, um banco de dados como o MySQL não é limitado por CPU, mas por IO , o que significa que não é a potência da CPU que está causando o gargalo na latência, é a latência de leitura e gravação e throughput do armazenamento secundário. Existem certos casos em que você pode estar vinculado à CPU, por exemplo, em alguns casos especiais ao executar determinadas somas de verificação em um dispositivo FusionIO, se precisar de SSL/outro tipo de criptografia, se executar operações matemáticas complexas no nível SQL ou aplicar filtros de linha que podem ser feitos exclusivamente na memória.

Se você sofreu picos de CPU no passado ou tem alto uso constante de CPU, isso pode ajudar , mas apenas supondo que você possa paralelizar o cálculo da consulta: isso não tornará a análise ALTER TABLES ou SQL mais rápida para uma única consulta. Isso, combinado com a abordagem "leve" que muitos de nós recomendamos ao trabalhar com o MySQL (tentar evitar a lógica de negócios -procedimentos armazenados- no lado do MySQL) torna o benchmark de laboratório que mencionei antes difícil de reproduzir na realidade. Começar a usar a simultaneidade extra às vezes requer uma versão recente do MySQL e alterações de configuração . Em geral, para o MySQL, é bem melhor investir em núcleos mais poderosos do que muitos deles .

InnoDBGenericName

O InnoDB pode acessar vários núcleos, mas não espere que seja assim fora da caixa. O InnoDB deve ser configurado para fazer isso.

• Mar 16, 2012: Usando vários núcleos para consultas MySQL únicas no Debian
• Sep 20, 2011: Múltiplos núcleos e desempenho do MySQL
• Sep 12, 2011: Possível fazer o MySQL usar mais de um núcleo?
• May 26, 2011: Sobre o desempenho de bancos de dados de thread único versus multithread

Se você não configurar os recursos multicore, as versões mais antigas do MySQL serão melhores

• Jun 19, 2011: Como eu executo corretamente um Bake-off do MySQL?
• Oct 05, 2011: A consulta é executada por muito tempo em algumas versões mais recentes do MySQL
• Nov 24, 2011: Por que mysql 5.5 é mais lento que 5.1 (linux, usando mysqlslap)

Ambientes VM

Quando se trata do MySQL em uma VM, o InnoDB deve ser tratado com muito cuidado e de forma muito conservadora. Por quê ?

Quando o InnoDB é usado pronto para uso (sem ajuste para threading), ele pode fornecer menos do que ganhos lineares. Você pode até dizer que nivela um pouco ( consulte a página 8 deste PDF ). O que pode piorar isso é o fato de que mais CPUs virtuais exigem maior sobrecarga de agendamento ( consulte a página 18 deste PDF ).

Epílogo

Conhecendo ambos os lados da questão do MySQL em uma VM, agora você pode ajustar moderadamente para obter mais Cpus. Isso é vital, pois você pode enlouquecer um pouco em um servidor bare metal se tiver muitos núcleos físicos junto com mais de 192 GB de RAM .

Portanto, para se beneficiar de mais CPUs, você deve ajustar o InnoDB com responsabilidade.

Você só pode ser um pouco mais liberal se

• Você aumenta os recursos físicos do VMWare (são necessários bolsos profundos e um CFO feliz)
• Você vai para um servidor bare metal