Tuning MariaDB Slow Query. Para acabar com as Slow Queries, não basta apenas aumentar a memória do servidor; é preciso identificar se o gargalo está na estrutura da consulta, na falta de índices ou na configuração do motor de banco de dados.
1. O Ponto de Partida: Slow Query Log
Antes de usar ferramentas externas, você precisa habilitar o diagnóstico nativo do MariaDB. Isso registrará qualquer consulta que demore mais do que um tempo X para ser executada.
Edite o arquivo /etc/my.cnf (ou o arquivo correspondente em /etc/my.cnf.d/):
Ini, TOML
slow_query_log = 1 slow_query_log_file = /var/lib/mysql/slow-queries.log long_query_time = 2 log_queries_not_using_indexes = 1
- long_query_time: Define o limite (em segundos). Para um ajuste fino, você pode baixar para
1ou até0.5. - log_queries_not_using_indexes: Crucial para identificar tabelas que estão forçando um “Full Table Scan”.
2. Ferramentas de Diagnóstico Essenciais
A. mysqldumpslow
Ferramenta nativa que resume o log de consultas lentas. Como os logs podem ficar gigantescos, ela agrupa consultas similares.
- Comando útil:
mysqldumpslow -s at -t 10 /var/lib/mysql/slow-queries.log(Exibe as 10 consultas com a maior média de tempo de execução).
B. MySQLTuner (Diagnóstico de Configuração)
Focada em parâmetros do my.cnf. Ela analisa o uptime do servidor e sugere ajustes no innodb_buffer_pool_size, query_cache, entre outros.
- Como usar:Bash
wget http://mysqltuner.pl/ -O mysqltuner.pl perl mysqltuner.plDica de Admin: No CloudLinux, preste atenção especial às recomendações de InnoDB Buffer Pool. Ele deve ser grande o suficiente para manter seus índices em RAM.
C. Percona Toolkit (pt-query-digest)
A ferramenta mais avançada para análise. O pt-query-digest gera um relatório detalhado com o impacto de cada query no sistema.
- Instalação (AlmaLinux/CentOS):
yum install percona-toolkit - Análise:
pt-query-digest /var/lib/mysql/slow-queries.log
3. Analisando a Query Individualmente: EXPLAIN
Ao identificar uma query lenta, você deve rodá-la manualmente no terminal do MariaDB prefixada pelo comando EXPLAIN.
SQL
EXPLAIN SELECT * FROM wp_posts WHERE post_status = 'publish' ORDER BY post_date DESC;
O que observar no resultado:
- type: Se aparecer
ALL, significa que o banco leu a tabela inteira. Procure porrefourange. - rows: Quantidade de linhas que o MariaDB precisou escanear.
- key: Indica qual índice foi usado. Se estiver
NULL, você tem um problema de indexação.
4. Monitoramento em Tempo Real
Se o servidor está travando agora, utilize o comando:
SQL
SHOW FULL PROCESSLIST;
Ou, para uma interface visual no terminal (estilo htop):
Bash
mytop # ou htop (pressionando F6 e escolhendo IO_READ/WRITE para ver o impacto do mysql)
Resumo de Boas Práticas
- Indexação: Nunca faça buscas por colunas que não possuem índices (especialmente em tabelas grandes de WordPress como
wp_optionsouwp_postmeta). - Limite o Resultado: Use
LIMITsempre que possível. - Memória: Garanta que o
innodb_buffer_pool_sizeocupe cerca de 50-70% da RAM disponível se o servidor for dedicado a banco de dados.
FAQ
Geralmente são causadas pela falta de índices em tabelas grandes, consultas mal estruturadas (JOINs ineficientes) ou falta de memória no innodb_buffer_pool_size.
Edite o arquivo my.cnf, defina slow_query_log = 1 e configure o long_query_time para o limite de segundos desejado.
As ferramentas mais recomendadas são o MySQLTuner para configurações do sistema e o pt-query-digest (Percona Toolkit) para análise profunda dos logs.

