Queries lentas no MySQL: diagnóstico prático

Para corrigir queries lentas no MySQL, registre primeiro as consultas problemáticas, leia o plano de execução e só então mexa em índices, cache ou servidor. Trocar plano sem medir costuma mascarar o erro: consulta ruim continua cara em qualquer VPS.

Onde a lentidão realmente aparece

O sintoma quase nunca nasce no painel do provedor. Ele aparece no tempo de resposta da aplicação, na fila de conexões, no uso de CPU do MySQL e nas leituras de disco que sobem quando uma consulta varre tabela demais.

O erro comum é procurar um plano maior antes de separar consulta ruim, índice ausente, cache pequeno e recurso insuficiente. Cada causa pede uma correção diferente. Misturar tudo encarece a hospedagem e deixa o gargalo esperando na mesma cadeira.

Em projeto brasileiro pequeno, a pressão costuma vir de WordPress, loja virtual, painel interno ou API que cresceu sem revisar consultas. O banco fica no mesmo VPS da aplicação, o horário comercial concentra acessos e qualquer busca sem índice vira fila.

O roteiro de diagnóstico

Comece pelo log de consultas lentas. Ele mostra quais consultas passaram do limite aceitável para a aplicação. Depois use o plano de execução para entender se o MySQL está usando índice, ordenando em disco ou lendo linhas demais.

Um fluxo seguro fica assim:

• Capture antes de mexer: guarde a consulta, o tempo percebido pela aplicação e o horário da ocorrência.
• Leia o plano de execução: procure varredura completa de tabela, índice ausente e estimativa de linhas muito alta.
• Corrija uma coisa por vez: altere índice, filtro ou ordenação e compare a mesma consulta de novo.
• Revise o cache: se as consultas melhoram depois da primeira execução, o gargalo pode estar no cache do InnoDB.
• Só escale servidor depois: CPU, RAM e disco entram na conta quando a consulta já está tecnicamente razoável.

Para investigação pontual, um administrador costuma começar com comandos como estes:

SHOW FULL PROCESSLIST;
EXPLAIN SELECT id, nome, status FROM pedidos WHERE status = 'pendente';

Em produção, não rode alteração de índice no impulso. Em tabelas grandes, criar índice também consome I/O e pode travar escrita se a janela for mal escolhida.

O que olhar no plano de execução

O plano de execução não é enfeite de console. Ele diz como o otimizador pretende chegar ao resultado. Se o banco lê quase tudo para devolver pouca coisa, a query está cobrando pedágio demais.

O melhor índice não é o índice em toda coluna. Índice acelera leitura, mas pesa escrita e ocupa armazenamento. Em sistemas com pedidos, sessões, carrinhos e logs, índice sem critério vira custo permanente.

Índice, cache ou servidor maior

Use índice quando a consulta filtra, junta ou ordena sempre pelas mesmas colunas. Use cache quando a mesma leitura se repete muito e não precisa refletir cada alteração instantânea. Use servidor maior quando a consulta já foi otimizada e ainda falta CPU, RAM ou I/O.

No Brasil, a troca de plano precisa considerar preço mensal e proximidade do público. KingHost, UOL Host e Locaweb têm ofertas locais nos dados da HostScout. Vultr aparece como opção global com região em São Paulo.

Essa tabela não escolhe vencedor. Ela mostra o ponto incômodo: se a query faz varredura desnecessária, pagar mais por CPU pode só comprar alguns minutos de folga. O ganho real vem de reduzir leitura e concorrência.

Quando mexer na consulta

Mexa na consulta quando o plano mostra leitura ampla, filtro sem índice ou retorno maior do que a aplicação usa. Troque SELECT com todas as colunas por uma lista explícita e revise filtros que aplicam função sobre a coluna.

Também desconfie de paginação profunda. Listagens com deslocamento muito alto obrigam o banco a caminhar por muitos registros antes de entregar a página pedida. Para telas operacionais, paginação por cursor costuma ser mais previsível.

JOIN lento não é culpa automática do MySQL. Verifique se as colunas ligadas têm tipos compatíveis, se a cardinalidade faz sentido e se a tabela principal foi escolhida por seletividade, não por hábito do desenvolvedor.

Quando mexer na infraestrutura

O servidor entra no diagnóstico quando consultas já enxutas continuam competindo por memória, CPU ou disco. Em VPS pequeno, MySQL e aplicação dividem o mesmo sistema operacional, os mesmos picos e a mesma margem de erro.

Escolha um plano com folga quando o banco precisa manter mais dados quentes em memória, quando relatórios concorrem com tráfego real ou quando backups e restaurações já atrapalham o horário de uso. Teste a restauração; backup sem teste é extintor com lacre bonito e utilidade duvidosa.

Evite trocar de provedor no escuro. Antes, compare latência para o público, janela de suporte, rotina de snapshot, política de backup, custo de migração e como o plano lida com uso sustentado de CPU. Suporte conta no relógio quando a loja está parada.

Como saber se a correção funcionou

Uma correção boa reduz tempo, linhas examinadas e variação sob carga parecida. Não basta a consulta parecer rápida uma vez no console. O banco pode estar com cache quente, pouca concorrência e nenhum relatório rodando junto.

Guarde uma amostra antes e depois. Compare a mesma rota da aplicação, com filtros equivalentes e volume parecido. Se a consulta melhora, mas o sistema segue lento, procure bloqueio de escrita, fila de conexão ou chamada externa travando a resposta.

Método e atualização dos dados

Os dados de planos e preços citados aqui vêm da base monitorada da HostScout e estavam atualizados nas datas indicadas nos metadados do artigo. Para decisão de compra, revise também backup, suporte, localização e custo de migração no momento da contratação.