Como Corrigir um Banco de Dados Lento do WordPress: Um Checklist de 4 Passos

O painel de administração do seu WordPress não deveria levar cinco segundos para carregar. Se isso acontece, o problema pode não ser seu plano de hospedagem ou suas imagens. Pode ser o seu banco de dados.

Seu banco de dados está silenciosamente acumulando anos de lixo, como transientes expirados, milhares de revisões de posts e dados autoload de plugins que você excluiu anos atrás.

A maior parte disso é invisível no wp-admin e não afeta o que os visitantes veem. Mas isso se acumula e, eventualmente, retarda tudo.

Eu já diagnostiquei sites onde um único plugin estava disparando 80 consultas de banco de dados por carregamento de página. A hospedagem estava boa. O cache estava configurado corretamente. Nada disso fez diferença até que o problema real do banco de dados fosse corrigido.

Neste post, mostrarei como identificar o gargalo, limpar o inchaço do banco de dados, corrigir as tabelas pesadas que sobrevivem à limpeza e reduzir a frequência com que o WordPress acessa o banco de dados em primeiro lugar.

Aqui estão os principais pontos:

• Um painel de administração lento quase sempre aponta para o banco de dados, não para sua hospedagem ou imagens. O painel ignora o cache de página, então é o sinal mais claro que você tem.
• Revisões de posts, transientes expirados, dados órfãos de plugins e opções autoload inchadas são os culpados mais comuns, e eles tendem a ser visíveis no wp-admin.
• Query Monitor (gratuito) identifica qual plugin ou consulta é o gargalo antes que você exclua qualquer coisa.
• DB Optimizer dá ao seu banco de dados uma pontuação de saúde em cinco categorias e mostra uma prévia completa do que será removido antes que você confirme a limpeza.
• Dados autoload em wp_options devem ficar abaixo de 1MB. Acima disso, cada carregamento de página carrega um peso desnecessário.
• O cache de objetos com Redis ou Memcached pode melhorar significativamente painéis de administração lentos que o cache de página não consegue resolver.
• Execute uma limpeza antes de cada backup ou migração importante. Um banco de dados menor significa uma transferência mais rápida e um arquivo de backup menor.

Sumário

O Que Causa a Lentidão do Banco de Dados do WordPress?

Antes de mergulhar nas correções, é útil saber com o que você está lidando. Bancos de dados do WordPress ficam lentos por razões previsíveis, e a maioria dos sites tem mais de um ao mesmo tempo.

Revisões de posts

Toda vez que você salva ou atualiza um post, o WordPress cria uma nova cópia. Em um site ativo, um único post pode ter dezenas de cópias de revisão armazenadas no banco de dados indefinidamente.

Elas são invisíveis para os visitantes, mas adicionam peso a cada consulta na tabela de posts.

Transientes expirados

Plugins usam transientes para armazenar temporariamente dados de chamadas de API externas e tarefas agendadas. Eles deveriam expirar e se excluir automaticamente.

Muitas vezes eles não o fazem, e os registros expirados se acumulam na tabela wp_options muito depois de terem qualquer utilidade.

Linhas órfãs e tabelas de plugins remanescentes

Quando um plugin é excluído, seus dados geralmente ficam para trás: campos personalizados, metadados de usuário, metadados de postagem e, às vezes, tabelas inteiras do banco de dados com o nome do plugin. Um site que passou por uma dúzia de plugins ao longo dos anos carrega os dados fantasmas de cada um.

Dados autoload em wp_options

Opções marcadas como autoload = yes carregam em todas as solicitações de página antes que o WordPress renderize qualquer coisa. Plugins que abusam dessa flag adicionam peso a cada carregamento de página, incluindo páginas que não têm nada a ver com esse plugin.

O total de dados autoloaded deve permanecer abaixo de 1 MB. Muitos sites lentos estão com 5 MB ou mais.

Fragmentação de tabelas

Quando as linhas são excluídas, o MySQL não recupera automaticamente o espaço que elas ocupavam. Com o tempo, as tabelas ficam fragmentadas e o MySQL tem que trabalhar mais para lê-las.

É por isso que executar um comando "Otimizar Tabela" pode acelerar as coisas, mesmo quando os dados em si parecem limpos.

Consultas lentas ou excessivas de plugins

Alguns plugins são simplesmente mal escritos. Eles executam dezenas de consultas em um único carregamento de página, ou consultam colunas que não estão indexadas, forçando o MySQL a escanear tabelas inteiras linha por linha em vez de pular para o registro correto.

Como Corrigir um Banco de Dados Lento do WordPress

Para corrigir um banco de dados lento do WordPress, você precisará descobrir o que está lento, remover a desordem que o causa, corrigir as tabelas que sobrevivem à limpeza e, em seguida, reduzir a frequência com que o banco de dados é consultado.

Veja o que você fará:

• Passo 1: Identifique o que está deixando seu banco de dados lento: use o plugin gratuito Query Monitor para ver cada consulta disparada em seu site, quanto tempo cada uma leva e qual plugin a acionou.
• Passo 2: Limpe o inchaço do banco de dados: use o DB Optimizer para pontuar seu banco de dados em cinco categorias de saúde, pré-visualizar exatamente o que é removido e limpá-lo com segurança com um limite de retenção integrado.
• Passo 3: Aborde tabelas pesadas: corrija o inchaço autoload em wp_options, ative o HPOS do WooCommerce, se relevante, verifique tabelas MyISAM que deveriam ser InnoDB e otimize o overhead da tabela sem o phpMyAdmin.
• Passo 4: Reduza a frequência com que o WordPress consulta o banco de dados: adicione cache de página, se ainda não o fez, e ative o cache de objetos com Redis ou Memcached para corrigir a lentidão do admin que o cache de página não consegue alcançar.

Passo 1: Identifique o Que Está Deixando Seu Banco de Dados Lento

Query Monitor é um plugin gratuito que mostra cada consulta de banco de dados disparada na página atual, quanto tempo cada uma leva e qual plugin ou tema a acionou. Instale-o no diretório de plugins do WordPress e ative-o como qualquer outro plugin.

Uma vez ativo, um novo item aparece na sua barra de administração mostrando a contagem total de consultas e o tempo de carregamento da página para qualquer tela em que você esteja. Clique nele para abrir o painel completo.

Vá para a aba Database Queries. Procure por consultas que levam mais de 0,05 segundos e por qualquer plugin que gere um número incomumente alto de chamadas.

O Query Monitor nomeia o plugin ou tema responsável diretamente, para que você não precise adivinhar.

Se um plugin está gerando 40 ou mais consultas por página ou tem consultas consistentemente acima de 0,05 segundos, esse é o seu gargalo. Desative-o e teste novamente.

Se nenhuma consulta específica se destacar, o problema é um inchaço geral distribuído pelo banco de dados, não um ator malicioso específico. Vá para a Etapa 2.

Uma coisa a verificar antes de prosseguir: o Query Monitor mostra apenas o comportamento na página atual. Execute-o no painel de administração, em uma página de produto do WooCommerce, se você tiver uma, e em uma postagem padrão.

A lentidão é frequentemente específica da página, e um problema de consulta na página de checkout não aparecerá enquanto você estiver olhando para o painel.

Passo 2: Limpe o Inchaço do Banco de Dados

A maioria das pessoas pula a limpeza do banco de dados porque não sabe o que é seguro excluir. Essa hesitação é razoável. Excluir a coisa errada em um banco de dados não pode ser desfeito.

DB Optimizer resolve isso mostrando exatamente o que está em seu banco de dados antes de remover qualquer coisa. A primeira coisa que você verá é uma pontuação de saúde de 0 a 100.

Ele se divide em cinco categorias: sobrecarga de tabelas, transientes, revisões, tamanho de autoload e itens da lixeira. Cada um recebe uma barra de progresso e uma nota codificada por cores.

Verde significa que a categoria está em boa forma. Amarelo significa que precisa de atenção. Vermelho significa que está diminuindo sua pontuação. Clique no botão Atualizar Pontuação a qualquer momento para atualizá-la.

Depois de saber o que está diminuindo a pontuação, vá para a guia Limpeza. Uma barra de resumo na parte superior mostra o número de itens disponíveis para limpeza e o espaço total recuperável em todo o seu banco de dados.

Abaixo disso, cada tipo de limpeza (Posts e Páginas, Comentários, Transientes e Cache) mostra uma contagem de itens e o tamanho estimado. Você pode ver exatamente com o que está lidando antes que algo seja excluído.

DB Optimizer tem um limite de retenção padrão de 7 dias. Qualquer coisa criada na última semana está fora de questão, independentemente dos tipos de limpeza que você selecionou.

Se você está se preparando para uma migração e quer um novo começo, diminua-o. Se você está trabalhando em um site sensível e quer cautela extra, aumente-o. Defina como 0 apenas se quiser limpar tudo, independentemente da idade. Sua preferência é salva automaticamente.

Após a limpeza, adicione uma linha ao seu arquivo wp-config.php para limitar as revisões futuras antes que elas se acumulem novamente:

define('WP_POST_REVISIONS', 3);

Adicione-a acima da linha que diz “Isso é tudo, pare de editar!” Isso limita o WordPress a manter três revisões por postagem daqui para frente.

DB Optimizer lida com o que já existe. Esta linha impede que ele retorne.

Passo 3: Resolva Tabelas Pesadas

A limpeza remove dados soltos, mas duas tabelas específicas causam lentidão contínua mesmo após uma limpeza completa: wp_options e wp_postmeta. O mecanismo de armazenamento que seu banco de dados usa também é importante aqui.

Dados autoload em wp_options

DB Optimizer mostra o tamanho do seu autoload como uma de suas cinco categorias de saúde. Se ainda estiver acima de 1 MB após a execução da limpeza, um plugin está escrevendo ativamente opções de autoload em cada execução. A limpeza remove entradas antigas, mas não pode impedir que novas sejam adicionadas.

Use a aba Query Monitor para ver o que está sendo carregado automaticamente e, em seguida, identifique qual plugin é o responsável. Desativá-lo ou entrar em contato com a equipe de suporte dele é a solução.

Wp_postmeta

Esta tabela armazena dados de campos personalizados e cresce rapidamente em sites com muitos recursos do WooCommerce ou ACF.

O Query Monitor sinalizará consultas nesta tabela se ela for um gargalo consistente. Corrigi-la no nível da consulta é território de desenvolvedor, mas saber que é o problema é metade da batalha.

Usuários do WooCommerce: ative o HPOS

Se você usa o WooCommerce, vá para WooCommerce » Configurações » Avançado » Recursos e ative o Armazenamento de Pedidos de Alto Desempenho.

Isso move os dados de pedidos do wp_postmeta para tabelas dedicadas e construídas para esse fim. Pode acelerar drasticamente as consultas de pedidos em qualquer loja com mais de algumas centenas de pedidos.

Após ativá-lo, o WooCommerce pode solicitar que você migre os dados de pedidos existentes. Execute a migração antes de prosseguir.

Motor de armazenamento: MyISAM vs. InnoDB

O MyISAM bloqueia a tabela de banco de dados inteira durante cada operação de gravação, o que causa filas sob qualquer carga de gravação significativa. O InnoDB bloqueia apenas a linha específica que está sendo gravada.

O WordPress usa o InnoDB por padrão desde o MySQL 5.7, mas sites migrados de ambientes de hospedagem mais antigos às vezes ainda têm tabelas MyISAM.

A aba Tabelas do DB Optimizer mostra o mecanismo de armazenamento de cada tabela. Se você vir tabelas MyISAM, convertê-las para InnoDB é uma mudança de SQL de uma linha, mas vale a pena passar para um desenvolvedor ou perguntar ao seu host se eles podem lidar com isso através do painel de controle deles.

Sobrecarga de tabelas

O DB Optimizer destaca qualquer tabela que esteja carregando sobrecarga e mostra um botão Otimizar ao lado dela. Você pode lidar com elas individualmente ou limpar toda a sobrecarga de uma vez.

Execute isso após a limpeza, pois a exclusão de linhas é o que cria a sobrecarga em primeiro lugar.

Passo 4: Reduza a Frequência com Que o WordPress Consulta o Banco de Dados

Mesmo um banco de dados limpo e otimizado é consultado a cada carregamento de página. As camadas de cache interceptam essas consultas para que o banco de dados trabalhe menos no geral.

O cache de página salva a saída HTML completa de uma página para que o WordPress pule o banco de dados completamente para essa solicitação.

Se você não tem um plugin de cache, adicione um antes de qualquer outra coisa. WP Rocket, W3 Total Cache e LiteSpeed Cache cuidam disso. O cache de página é a mudança de maior impacto que você pode fazer para os visitantes do frontend.

Você também deve ativar o cache de objetos. O cache de objetos salva resultados individuais de consultas ao banco de dados na memória do servidor para que consultas repetidas acessem o cache em vez do banco de dados.

Solicitações de administrador, checkouts do WooCommerce e qualquer página que não possa ser totalmente armazenada em cache se beneficiam disso.

Pergunte ao seu host se Redis ou Memcached estão disponíveis. Muitos hosts gerenciados de WordPress incluem um ou ambos.

Se o Redis estiver disponível, instale o plugin Redis Object Cache e siga as instruções de conexão do seu host. O plugin exibe um status Conectado quando está funcionando corretamente.

Não instale o Redis Object Cache, a menos que seu host realmente forneça um servidor Redis. Sem uma conexão ativa, o plugin gera erros e não oferece nenhum benefício.

Opcional: Comandos WP-CLI para Corrigir um Banco de Dados Lento

Se você gerencia o WordPress pela linha de comando, estes comandos cobrem o mesmo terreno que as etapas acima, sem a interface de um plugin.

wp db optimize

Executa a utilidade de otimização do MySQL em todas as tabelas do banco de dados.

wp transient delete --expired

Remove todos os transientes expirados do wp_options.

wp post delete $(wp post list --post_status=trash --format=ids)

Exclui permanentemente todas as postagens atualmente na lixeira.

wp post delete $(wp post list --post_type='revision' --format=ids)

Exclui todas as revisões de postagem armazenadas.

Faça backup com o Duplicator antes de executar qualquer um destes. Eles executam imediatamente, sem etapa de visualização e sem prompt de confirmação.

O WP-CLI não fornece a pontuação de integridade, os limites de retenção ou as visualizações por categoria que o DB Optimizer oferece. Ele apenas oferece um caminho mais rápido para as mesmas tarefas de limpeza.

Solução de Problemas: Quando o Banco de Dados Ainda Está Lento

Se você seguiu todas estas etapas e o site ainda está lento, um destes cenários é provavelmente a causa.

Query Monitor Não Mostra um Culpado Óbvio

O que você vê: cada consulta individual está abaixo de 0,05 segundos, mas a página ainda carrega lentamente.

O problema pode ser o volume total de consultas, não uma única consulta lenta. Duzentas consultas a 0,01 segundos cada ainda adicionam dois segundos completos de tempo de banco de dados antes que qualquer coisa seja renderizada.

Verifique a barra de resumo no Query Monitor. Se o número total de consultas estiver acima de 50 a 75 em uma página padrão, vale a pena investigar.

Desative os plugins um por um, recarregue a página após cada desativação e observe a contagem diminuir. O plugin que causa a maior queda é o seu alvo.

O Tamanho do Autoload Permanece Alto Após a Limpeza

O que você vê: o DB Optimizer ainda mostra o tamanho do autoload acima de 1 MB após a execução da limpeza.

A limpeza remove entradas expiradas e órfãs do autoload, mas não pode impedir que um plugin grave novas. Se o número continuar a subir, algo está adicionando ativamente ao pool de autoload a cada solicitação.

O Query Monitor mostra cada opção sendo carregada automaticamente na página atual. Procure por entradas de plugins que você não reconhece ou não usa ativamente, em seguida, desative esses plugins um por um e atualize a pontuação.

O Checkout do WooCommerce Ainda Está Lento Após a Limpeza

O que você vê: as páginas de checkout levam de três a cinco segundos para carregar após a limpeza.

O HPOS pode estar ativado, mas a migração de dados pode não estar completa. Vá para WooCommerce » Status » Ferramentas e procure por uma opção Migrar dados de pedidos. Se estiver lá, execute-a.

Migrações incompletas deixam o WordPress lendo de ambas as estruturas de tabelas, antiga e nova, simultaneamente, o que é mais lento do que qualquer uma delas isoladamente.

Se a migração já estiver completa, um plugin conflitante pode estar forçando o WooCommerce de volta para as tabelas de pedidos legadas. Desative os plugins um por um e teste a velocidade do checkout após cada um.

O Cache de Objetos Mostra Conectado, Mas o Admin Ainda Está Lento

O que você vê: o plugin Redis Object Cache mostra "Conectado", mas as páginas de administração ainda estão lentas.

Um plugin provavelmente está limpando o cache de objetos a cada solicitação, o que anula o propósito de tê-lo. Abra o Query Monitor e verifique o cache. Se a taxa de acertos do cache estiver abaixo de 80%, algo está limpando agressivamente.

Identifique-o desativando plugins em grupos de dois ou três, verificando a proporção após cada grupo. Quando a proporção de acertos aumentar, o último grupo que você desativou contém o problema.

Nada Está Funcionando

Se todas as quatro etapas forem concluídas e o desempenho não tiver melhorado, o problema provavelmente está fora do próprio banco de dados. Memória MySQL insuficiente em hospedagem compartilhada força o servidor a usar troca de disco em vez de RAM, o que nenhuma limpeza resolverá.

Entre em contato com seu provedor e pergunte especificamente sobre a alocação de memória MySQL e se o registro de consultas lentas no lado do servidor está disponível. Um desenvolvedor que revisa o log de consultas lentas pode identificar problemas que o Query Monitor não consegue capturar.

Perguntas Frequentes (FAQs)

Seu Banco de Dados Não Vai se Limpar Sozinho

Você fez algo que a maioria dos proprietários de sites WordPress nunca faz: diagnosticou um gargalo no banco de dados, limpou dados que se acumularam por anos, abordou as tabelas específicas que causam lentidão persistente e reduziu a frequência com que o banco de dados precisa trabalhar.

Daqui para frente, execute a verificação de integridade do DB Optimizer uma vez por mês. O inchaço do banco de dados retorna gradualmente e uma verificação mensal evita que ele se acumule.

E lembre-se de que a otimização modifica permanentemente seu banco de dados. Um backup antes de começar é a diferença entre um erro corrigível e um permanente.

Mais de 1,5 milhão de profissionais de WordPress usam o Duplicator para fazer backup e migrar seus sites. O plano gratuito cobre backups completos do site e leva cerca de dois minutos para configurar. Atualize para armazenamento em nuvem, backups automáticos e um plugin gratuito DB Optimizer com Duplicator Pro!

Se este guia ajudou, estes posts também valem a pena ser marcados.

• Como Otimizar Seu Banco de Dados WordPress
• Aqui Estão os Passos de Reparo do Banco de Dados do WordPress Que Eu Mesmo Fiz
• Manutenção do Banco de Dados do WordPress: O Que Fazer Semanalmente, Mensalmente e Trimestralmente
• Como Fazer Backup de um Banco de Dados WordPress
• O Melhor Plugin de Otimização de Banco de Dados do WordPress Que Já Usei (Mais 3 Alternativas)