Otimizar MySQL/MariaDB na VPS: o tuning essencial

A instalação padrão do MySQL/MariaDB é deliberadamente conservadora — feita para rodar até em máquinas minúsculas. O resultado: numa VPS com RAM de sobra, o banco usa uma fração do que poderia e fica mais lento do que precisa. Alguns ajustes certos podem dobrar o desempenho sem trocar de hardware. Veja o que move o ponteiro de verdade.

Antes de tudo: meça

Não otimize no escuro. Descubra onde está o gargalo:

• SHOW STATUS / SHOW ENGINE INNODB STATUS — estado interno do banco.
• Slow query log — registra as consultas lentas (o maior culpado quase sempre).
• Ferramentas como mysqltuner dão um diagnóstico rápido e recomendações.

A regra: a maior parte dos ganhos vem de poucas consultas lentas e de um parâmetro de memória. Foque no que importa.

O ajuste nº 1: innodb_buffer_pool_size

Se você mudar um parâmetro, mude este. O buffer pool é a memória onde o InnoDB (o motor padrão) guarda dados e índices. Quanto mais dados cabem nele, menos o banco vai ao disco — e disco é lento comparado à RAM.

Regra prática num servidor dedicado ao banco: 50–70% da RAM para o buffer pool. Numa VPS que também roda o site/app, seja mais conservador (ex.: 25–40%), deixando memória para o PHP e o web server.

# em /etc/mysql/mariadb.conf.d/50-server.cnf (ou my.cnf)
[mysqld]
innodb_buffer_pool_size = 1G

Ajuste 1G ao tamanho real da sua VPS. Esse único parâmetro costuma ser o maior salto de desempenho.

Índices: o outro grande ganho

Um índice é como o índice remissivo de um livro — sem ele, o banco lê a tabela inteira para achar uma linha (full table scan). Com ele, vai direto.

• Crie índices nas colunas usadas em WHERE, JOIN e ORDER BY.
• Use EXPLAIN antes de uma consulta para ver se ela usa índice ou varre a tabela toda.
• Não exagere: índice demais deixa a escrita mais lenta. Indexe o que as consultas realmente filtram.

Uma consulta lenta quase sempre é uma consulta sem índice. Esse costuma ser o maior ganho depois do buffer pool.

Outros parâmetros úteis

[mysqld]
# Log de consultas lentas (ache os gargalos)
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

# Conexões — ajuste ao seu app (nao exagere: cada conexao custa RAM)
max_connections = 100

# Flush do log: 2 e mais rapido; 1 e mais seguro (padrao)
innodb_flush_log_at_trx_commit = 2

⚠️ Cuidado com max_connections muito alto: cada conexão consome memória. Um número inflado pode estourar a RAM num pico e derrubar o banco. Ajuste ao que o app usa de verdade.

Manutenção que mantém o desempenho

• OPTIMIZE TABLE periodicamente em tabelas com muita escrita/exclusão (desfragmenta).
• Limpe dados velhos — logs, sessões expiradas, revisões (num WordPress, use um plugin de limpeza).
• Mantenha o MySQL/MariaDB atualizado — versões novas trazem ganhos de performance de graça. Veja atualizações no Linux.

Some cache de objeto para as leituras repetidas

Muito do que um app pede ao banco se repete. Um cache de objeto (Redis) guarda esses resultados em memória e alivia o banco enormemente — especialmente em apps com muita leitura. Veja Redis para acelerar apps.

Tuning pede RAM e controle — pede VPS

Você só afina o banco de verdade quando controla a configuração e tem RAM dedicada: exatamente o que uma VPS oferece. A VittHost tem VPS com boa memória, SSD e root, no Brasil e no Canadá:

👉 Ver planos de VPS

Banco afinado? Não esqueça do backup — desempenho sem backup é risco.