Guia completo para otimização de perfomance do mariadb

By HelpSysAdminGerenciamento de Servidor, Linux

Este é um guia técnico abrangente para otimizar o MariaDB. A performance de um banco de dados depende de três pilares: Hardware/OS, Configuração (my.cnf) e Consultas (Queries/Indexes).

Abaixo, detalho cada camada, focando nas configurações mais impactantes.

1. Otimização do Sistema Operacional (OS)

Antes de tocar no MariaDB, o ambiente deve estar preparado.

  • Swappiness: O banco de dados nunca deve usar SWAP, pois a performance de disco é drasticamente inferior à RAM.
    • Adicione ao /etc/sysctl.conf: vm.swappiness = 1 (ou 0). Após editar o arquivo execute sysctl -p para aplicar as alterações sem reiniciar o servidor.
  • Filesystem: Prefira XFS ou ext4. XFS geralmente lida melhor com grandes volumes de dados e concorrência.
  • File Descriptors: Aumente o limite de arquivos abertos.
    • No /etc/security/limits.conf:
      mysql soft nofile 65535
      mysql hard nofile 65535

2. Otimização do Engine InnoDB (my.cnf)

O arquivo de configuração geralmente reside em /etc/my.cnf ou /etc/my.cnf.d/server.cnf. O InnoDB é o engine padrão e o mais importante para tunar.

A. Memória (O Fator Mais Crítico)

  • innodb_buffer_pool_size: Esta é a variável mais importante. Ela define quanto da RAM o MariaDB usará para cachear dados e índices.
    • Servidor Dedicado: Defina entre 60% a 80% da RAM total.
    • Servidor Compartilhado (Web + DB): Defina entre 30% a 50%, deixando espaço para o Apache/Nginx e PHP.
    • Fórmula: $$BufferPool = TotalRAM \times 0.75$$ (para dedicados).
  • innodb_buffer_pool_instances: Divide o pool em regiões para reduzir a contenda de threads.
    • Se o buffer pool for > 1GB, defina este valor igual ao número de núcleos de CPU (até um limite razoável, ex: 8 ou 16).

B. Log e Escrita (I/O)

  • innodb_log_file_size: Tamanho dos arquivos de log de refação (Redo Logs). Valores maiores melhoram a performance de escrita, mas aumentam o tempo de recuperação após um crash.
    • Recomendado: 1GB a 4GB (dependendo do tráfego de escrita).
  • innodb_flush_log_at_trx_commit: Controla a garantia ACID.
    • 1 (Padrão): Mais seguro. Grava no disco a cada transação. Mais lento.
    • 2 (Otimizado): Grava no cache do OS a cada transação e no disco a cada segundo. Muito mais rápido, risco de perda de 1s de dados em caso de falha de energia (mas não em crash do MySQL). Recomendado para a maioria dos servidores web.
    • 0: Máxima velocidade, maior risco.
  • innodb_flush_method: Como o MariaDB interage com o disco.
    • Linux: Use O_DIRECT. Isso evita que o OS faça cache do que o MariaDB já cacheou, economizando RAM (evita “double buffering”).

3. Buffers e Conexões

Cuidado aqui: muitas dessas configurações são por thread (conexão). Valores altos multiplicados por muitas conexões podem estourar a RAM (OOM Killer).

  • max_connections: Não defina arbitrariamente alto. Use o histórico de conexões simultâneas (Max_used_connections) e adicione uma margem de 20%.
  • thread_cache_size: Mantém threads abertas para reuso.
    • Fórmula básica: 8 + (max\_connections / 100).
  • tmp_table_size e max_heap_table_size: Devem ter o mesmo valor. Determinam o tamanho das tabelas temporárias em memória antes de serem gravadas em disco.
    • Recomendado: 64M a 128M (Cuidado para não exagerar).

4. Query Cache (Atenção!)

No MariaDB moderno e MySQL 8.0+, o Query Cache é frequentemente desencorajado ou removido, pois causa “lock” em ambientes de alta concorrência.

  • Recomendação: Desative-o (query_cache_type = 0 e query_cache_size = 0) e confie no cache do InnoDB ou em cache de aplicação (Redis/Memcached).

5. Otimização de Consultas (Queries)

Nenhuma configuração de servidor salva uma query mal escrita.

Slow Query Log: Ative para identificar os vilões:

Comando EXPLAIN: Use antes de qualquer SELECT pesada para ver se índices estão sendo usados.

  • Busque por type: ALL (scan completo da tabela – ruim).
  • Busque por type: ref ou eq_ref (uso de índice – bom).

6. Ferramentas de Diagnóstico Automatizado

Não tente adivinhar. Use scripts que analisam o estado atual do servidor e sugerem ajustes.

MySQLTuner: Script em Perl que analisa o uptime e sugere variáveis.

Nota: Execute o tuner apenas após o servidor estar rodando há pelo menos 24 horas para ter dados estatísticos reais.

Percona Toolkit: O pt-query-digest é excelente para analisar o slow log e gerar relatórios de quais queries consomem mais recursos.

Resumo do my.cnf (Exemplo para servidor com 16GB RAM)

Aqui está um exemplo base (“boilerplate”) para um servidor dedicado de 16GB de RAM. Ajuste conforme necessário.

Clique aqui e consulte nossos planos de Gerenciamento de Servidor

Veja Mais: Como Instalar Openlitespeed no Ubuntu 20.04
Veja Mais: Como Usar htop, iotop e Glances para Diagnóstico Rápido de Servidores Linux
Veja Mais: Como configurar lamp com wordpress e let´s encrypt
Veja Mais: Como configurar lemp com wordpress e let´s encrypt
Veja Mais: Como lidar com load alto no servidor