Diagnóstico de slow queries no MySQL: o método completo

Consultas lentas raramente avisam antes de derrubar a aplicação. Elas se acumulam silenciosamente até que um pico de tráfego transforma um problema latente em incidente. Este artigo documenta o método que usamos em diagnósticos de performance: capturar, medir e priorizar — nessa ordem.

1. Ative o slow query log (corretamente)

O primeiro passo é ter dados. Sem histórico de consultas lentas, qualquer otimização é chute. No MySQL 8, a configuração mínima recomendada:

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.5;
SET GLOBAL log_queries_not_using_indexes = ON;

O valor de long_query_time importa pouco em produção com tráfego alto — o objetivo é amostrar, não registrar tudo. Meio segundo é um bom ponto de partida; ajuste para baixo se o log ficar raso.

Cuidado com long_query_time = 0 em servidores ocupados: o arquivo cresce rápido e o I/O de disco compete com o próprio banco que você está tentando diagnosticar.

2. Use o performance_schema para a visão agregada

O slow log mostra eventos individuais. Para enxergar o padrão, o performance_schema agrega por digest de consulta:

SELECT
  DIGEST_TEXT                                   AS consulta,
  COUNT_STAR                                    AS execucoes,
  ROUND(SUM_TIMER_WAIT / 1e12, 2)               AS total_seg,
  ROUND(AVG_TIMER_WAIT / 1e9, 1)                AS media_ms,
  ROUND(MAX_TIMER_WAIT / 1e9, 1)                AS pior_ms,
  SUM_NO_INDEX_USED                             AS sem_indice
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME = 'producao'
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

A coluna SUM_TIMER_WAIT é a mais importante: uma consulta de 30 ms executada 50 mil vezes por dia pesa mais que uma consulta de 4 segundos rodada uma vez por hora. Otimize pelo total, não pelo pico isolado.

3. Priorize com a matriz impacto × esforço

Com os dados agregados, classifique cada candidata em uma matriz simples:

O ranking de produtos domina o total e se resolve com um índice — é a correção óbvia. O relatório mensal é lento, mas roda fora do horário de pico e não afeta o usuário.

4. Valide antes e depois

Nunca confie em “parece mais rápido”. Meça com EXPLAIN ANALYZE (MySQL 8.0.18+), que executa a consulta e mostra o plano real com tempos por operação:

EXPLAIN ANALYZE
SELECT cliente_id, SUM(valor)
FROM pedidos
WHERE status = 'pago' AND criado_em >= '2026-01-01'
GROUP BY cliente_id;

Compare o tempo total antes e depois da mudança e confirme no performance_schema nas 24 horas seguintes que o SUM_TIMER_WAIT caiu de fato.

Conclusão

Diagnóstico de slow queries é um processo de evidência: log para capturar, performance_schema para agregar, matriz para priorizar e EXPLAIN ANALYZE para validar. Ferramenta nenhuma substitui esse ciclo. Se o seu banco precisa de um diagnóstico estruturado, veja como trabalhamos em nossos serviços de consultoria MySQL.