Como otimizar o banco de dados do WordPress achando consultas lentas

Para otimizar o banco de dados do WordPress com segurança, comece pelo diagnóstico e deixe os plugins de limpeza para depois. Primeiro, faça um backup e prepare uma cópia local ou em staging, porque é lá que o diagnóstico deve rodar, não no site em produção. Em seguida, ative a constante SAVEQUERIES no wp-config.php e leia o array $wpdb->queries, que mostra cada consulta, o tempo que ela levou e a função que a chamou. Assim você descobre qual plugin ou tema está pesando. No fim, desligue a depuração.

A lógica é simples. Limpar tabelas sem saber de onde vem a lentidão é como trocar o óleo de um carro com o pneu furado: dá trabalho e o problema continua. Se a consulta lenta vem de um plugin, ela volta a aparecer logo depois da faxina.

O que você precisa antes de ativar o SAVEQUERIES

Você precisa de três coisas: um ambiente de teste, um backup recente e acesso para editar o wp-config.php.

O ambiente de teste e o backup não se substituem, um complementa o outro:

• Uma cópia local ou em staging, que é onde o SAVEQUERIES deve ser ativado. A documentação oficial de depuração desaconselha usar WP_DEBUG e as outras ferramentas de depuração em sites em produção, porque elas foram feitas para testes locais e instalações de staging.
• Um backup do banco de dados, como rede de segurança antes de mexer no wp-config.php ou limpar tabelas. Siga o guia oficial Backing Up Your Database. Se o seu site está na Hostinger, há um passo a passo para fazer o backup com banco e arquivos e restaurar na ordem certa. O backup protege seus dados, mas não transforma a produção em lugar indicado para depurar.

Você também precisa conseguir abrir e salvar o wp-config.php, seja pelo gerenciador de arquivos da hospedagem, por FTP ou por outro acesso que você já use.

Como encontrar consultas lentas no WordPress passo a passo

O processo tem quatro passos: abrir o wp-config.php e localizar o ponto certo de edição, ativar o registro das consultas, configurar o log e ler os dados salvos. A análise desses dados para identificar o plugin ou tema responsável vem na seção seguinte. Os trechos de código abaixo são exemplos didáticos baseados na documentação oficial.

1. Abra o wp-config.php e encontre o ponto certo de edição. Segundo a página oficial sobre como editar o wp-config.php, as constantes personalizadas entram antes da linha That's all, stop editing! Happy publishing. Em versões antigas, essa linha termina com "Happy blogging".

   Erro comum deste passo: colar os define() depois dessa linha. Quem nunca fez isso, né? O lugar certo é sempre acima do comentário.

2. Ative o SAVEQUERIES. Com essa constante em true, o WordPress salva cada consulta ao banco, o tempo de execução e a função que a chamou.

   define( 'SAVEQUERIES', true );

3. Configure o log sem expor nada aos visitantes. A configuração de exemplo da documentação oficial grava tudo em debug.log e não exibe mensagens na página:

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_LOG', true );
   define( 'WP_DEBUG_DISPLAY', false );
   @ini_set( 'display_errors', 0 );

   O WP_DEBUG_LOG complementa o WP_DEBUG e grava os erros no arquivo debug.log, que normalmente fica em wp-content/debug.log.

   Erro comum deste passo: esquecer o WP_DEBUG_DISPLAY. O padrão dele é true, ou seja, as mensagens de depuração aparecem no HTML das páginas. Com false, elas ficam ocultas.

4. Leia o $wpdb->queries. A documentação mostra duas formas de fazer isso. A primeira grava todas as consultas no log:

global $wpdb;
error_log( print_r( $wpdb->queries, true ) );

A segunda exibe as consultas na tela, mas só para administradores:

if ( current_user_can( 'administrator' ) ) {
    global $wpdb;
    echo '<pre>';
    print_r( $wpdb->queries );
    echo '</pre>';
}

Coloque o trecho em um código que rode depois das consultas que você quer observar. Se ele rodar cedo demais, a lista vai sair incompleta.

Erro comum deste passo: tentar ler $wpdb->queries com o SAVEQUERIES desligado. Esse array só existe quando a constante está ativa, então sem ela não há nada para ler.

Como interpretar $wpdb->queries para achar o plugin ou tema culpado

Cada registro do $wpdb->queries traz três informações: a consulta SQL, quanto tempo ela levou para executar e qual função a chamou. Essa última é a parte mais útil para o diagnóstico.

Para verificar o resultado, siga esta ordem:

• Procure os maiores tempos. Percorra a lista e anote as consultas que demoram mais do que as outras na mesma requisição. A documentação oficial não define um limite em segundos para considerar uma consulta "lenta". Por isso, a comparação é relativa: o que destoa do restante merece atenção.
• Olhe a função de origem. O nome da função ou da classe costuma dar uma pista de quem a criou. Busque esse nome no código dos plugins e do tema ativo para confirmar quem é o responsável.
• Observe a repetição. Às vezes nenhuma consulta é lenta sozinha, mas a mesma função dispara várias consultas parecidas em uma única página. Isso também pesa.

Com o responsável identificado, você tem três saídas: ajustar a configuração do plugin ou do tema, substituí-lo por outro ou desativá-lo. Tudo isso vem antes de qualquer limpeza de tabelas.

Como desligar a depuração depois do diagnóstico

Terminou de investigar? Volte o wp-config.php ao estado original. Você pode remover as linhas que adicionou ou trocar os valores para false:

define( 'SAVEQUERIES', false );
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );

A documentação oficial explica por que isso importa. O SAVEQUERIES afeta o desempenho do site e deve ser desligado quando a depuração termina. Além disso, com o WP_DEBUG ativo, erros e informações podem ser expostos a visitantes ou gravados em um arquivo acessível publicamente.

Erro comum deste passo: esquecer a depuração ligada depois de resolver o problema. A própria documentação aponta isso como algo comum.

Para a checagem final, faça o seguinte:

• Confira se os define() voltaram exatamente ao que eram antes do diagnóstico.
• Remova ou guarde em local seguro o arquivo wp-content/debug.log que foi gerado, já que ele pode ficar acessível publicamente.
• Apague o trecho que lia o $wpdb->queries, caso você o tenha colocado em algum arquivo do site.

Se você quiser transformar essa rotina de revisão em hábito, vale ler sobre como automatizar a manutenção do WordPress com atualizações e backups.

Otimizador com IA da Hostinger como complemento ao diagnóstico

Se o seu site está na hospedagem WordPress da Hostinger, existe uma ferramenta que trabalha no mesmo problema por outro caminho. A página oficial da hospedagem WordPress anuncia um otimizador de sites com IA que aplica otimizações do LiteSpeed e detecta consultas lentas automaticamente.

Na mesma página, a Hostinger afirma que o otimizador aumenta o desempenho do site em 20%. Trate esse número como uma alegação do fabricante. O ganho real depende do site e não é garantido.

Sobre o ambiente, a página de hospedagem gerenciada informa que a infraestrutura usa servidores LiteSpeed e oferece uma ferramenta de staging para WordPress, com disponibilidade que depende do plano. Já o artigo de suporte sobre velocidade diz que o plugin LiteSpeed Cache é instalado automaticamente para usuários de WordPress.

Mesmo assim, veja o otimizador como um complemento. Ele pode apontar consultas lentas, mas é o $wpdb->queries que mostra a função de origem de cada consulta, e é isso que leva você até o plugin ou tema exato. Se o seu plano tiver staging, use esse ambiente para rodar o SAVEQUERIES sem mexer no site em produção.

Próximo passo depois de achar a consulta lenta

Pegue a função que mais apareceu no seu diagnóstico e resolva a origem dela. Ajuste a configuração, troque o plugin ou desative o recurso no staging e depois rode o SAVEQUERIES de novo na mesma página. Se a consulta sumiu ou ficou mais rápida que as outras, a correção funcionou.

Só depois disso faz sentido partir para a limpeza de tabelas, sempre com um backup recente feito antes.

Se o seu WordPress roda em um servidor próprio e a lentidão continuar mesmo com plugins e tema em ordem, o próximo nível é otimizar o MySQL na VPS. Nesse cenário, a configuração do servidor fica por sua conta.

Explore os vídeos do canal Hora de Codar.

Transparência: a Hostinger é parceira da Hora de Codar, e é nas VPS dela que rodam o nosso blog e os nossos sistemas. Esta recomendação vem do que usamos todo dia.