Fazer o tuning MariaDB e MySQL através do arquivo my.cnf (ou 50-server.cnf em instalações modernas) é o passo mais rápido para transformar um banco de dados engasgado em uma máquina de alta performance. As configurações padrão geralmente são conservadoras, projetadas para rodar em servidores pequenos sem consumir todos os recursos.
Se você tem um servidor dedicado para o seu banco de dados, não fazer um tuning MariaDB e MySQL é um verdadeiro desperdício de hardware.
Aqui estão as 5 variáveis fundamentais que você deve ajustar hoje, com um foco especial no motor InnoDB.
1. innodb_buffer_pool_size (O Coração da Performance)
No universo do tuning MariaDB e MySQL, esta é, sem dúvida, a variável mais importante do seu servidor.
O Buffer Pool é a área de memória (RAM) onde o InnoDB faz o cache dos dados das tabelas e dos índices. Quando os dados estão no Buffer Pool, o banco de dados não precisa ir até o disco rígido (que é muito mais lento) para buscar as informações.
- A Regra de Ouro: Se o seu servidor é dedicado apenas ao banco de dados, você deve alocar de 60% a 80% da memória RAM total do servidor para esta variável.
- Atenção: Se o servidor compartilha recursos com um servidor web ou PHP, seja mais conservador (ex: 30% a 50%) para evitar o uso de memória Swap.
Exemplo no /etc/my.cnf:
innodb_buffer_pool_size = 12G
2. innodb_buffer_pool_instances (Para Alta Concorrência)
Um bom tuning MariaDB e MySQL não foca apenas em tamanho, mas na concorrência. Ter um Buffer Pool gigante é ótimo, mas se muitas threads tentarem ler e escrever nele ao mesmo tempo, elas podem criar um “engarrafamento”.
Dividir o Buffer Pool em várias instâncias permite que diferentes threads operem em áreas distintas da memória simultaneamente.
- Como ajustar: Configure 1 instância para cada 1GB de
innodb_buffer_pool_size(limite útil entre 8 e 16).
Exemplo no my.cnf:
innodb_buffer_pool_instances = 8
3. innodb_log_file_size (Performance de Escrita)
Um erro comum ao ignorar o tuning MariaDB e MySQL é manter os arquivos de log (Redo Logs) muito pequenos. O InnoDB grava todas as alterações de dados primeiro nestes arquivos.
Se eles forem muito pequenos, o banco precisará gravar no disco definitivo com muita frequência, causando picos de lentidão em INSERT, UPDATE e DELETE.
- Como ajustar: Um bom ponto de partida é cerca de 25% do tamanho do seu Buffer Pool, ou valores entre 1G e 4G.
Exemplo no my.cnf:
innodb_log_file_size = 2G
4. innodb_flush_log_at_trx_commit (Velocidade vs. Segurança)
Se você quer sentir o impacto imediato do seu tuning MariaDB e MySQL em operações de escrita, este é o maior “botão de velocidade”, mas envolve um risco calculado.
1(Seguro): Grava no disco a cada transação. Mais lento, porém ideal para dados financeiros.2(Melhor Custo-Benefício): Envia a transação para o cache do SO imediatamente, gravando no disco físico 1 vez por segundo. A performance de escrita aumenta absurdamente.0(Mais Rápido): Grava no disco 1 vez por segundo. Risco ligeiramente maior de perda de dados (1 segundo) caso o serviço trave.
Exemplo no my.cnf:
innodb_flush_log_at_trx_commit = 2
5. max_connections (Estabilidade do Servidor)
Nenhum tuning MariaDB e MySQL está completo sem garantir a estabilidade de acessos simultâneos. Esta variável define o número máximo de conexões permitidas, evitando o erro fatal Too many connections.
- Como ajustar: Valores entre 500 e 2000 são comuns para web. Cuidado: não coloque valores altos se não tiver RAM suficiente.
Exemplo no my.cnf:
max_connections = 1000
Dica de Ouro: Após aplicar essas práticas de tuning MariaDB e MySQL no seu arquivo, você precisará reiniciar o serviço do banco de dados para que as configurações entrem em vigor.
FAQ:
innodb_buffer_pool_size?Para um servidor dedicado exclusivamente ao banco de dados, a recomendação padrão é alocar entre 60% e 80% da memória RAM total disponível para o innodb_buffer_pool_size. Se o servidor compartilha recursos com aplicações web (como PHP ou Apache), utilize valores mais baixos, entre 30% e 50%, para evitar o uso de memória Swap.
innodb_flush_log_at_trx_commit 1 e 2O valor 1 (padrão) grava os dados no disco físico a cada transação, sendo a opção mais segura, porém a mais lenta. O valor 2 envia a transação para o cache do sistema imediatamente, mas só grava no disco físico uma vez por segundo. O valor 2 oferece um ganho gigantesco de performance com um risco baixíssimo de perda de dados (máximo de 1 segundo em caso de queda de energia no servidor).
Sim. A maioria das configurações estruturais de memória e log, como o innodb_buffer_pool_size e o innodb_log_file_size, exigem que o serviço do MariaDB ou MySQL seja reiniciado para que as novas variáveis entrem em vigor no sistema.
Veja Mais:
Otimizar MariaDB em 5 Minutos: Guia Prático do my.cnf em Produção
TCP Tuning para WordPress: Guia de Alta Performance
Guia completo para otimização de perfomance do mariadb
Como testar a velocidade da internet do servidor linux com speedtest-cli

