Como Realizar uma Verificação de Integridade do Banco de Dados do WordPress em 15 Minutos

O WordPress vem com uma ferramenta chamada Integridade do Site. A maioria das pessoas a usa para dar uma olhada rápida na integridade do banco de dados, mas ela não pode limpar nada.

A Saúde do Site não é uma ferramenta completa de auditoria de banco de dados. Ela informa o tamanho do banco de dados, a versão do servidor/cliente e o conjunto de caracteres, e verifica a contagem e o tamanho agregado das opções autoload. Ela não audita revisões, sobrecarga de tabelas, resíduos transitórios ou tabelas de plugins.

Nesta postagem, mostrarei como executar uma verificação de integridade real do banco de dados do WordPress, como cada número deve parecer e o que vale a pena agir. Leva cerca de 15 minutos.

Ao final, você terá cinco números registrados, um veredito sobre cada um e uma data para verificá-los novamente.

Principais conclusões:

• O WordPress tem uma ferramenta chamada Saúde do Site, mas ela não oferece uma verificação abrangente da integridade do banco de dados. Ela informa o tamanho, a versão e o conjunto de caracteres, e mede pouco sobre o que está dentro.
• A Saúde do Site fornece uma linha de base de tamanho gratuita em cerca de 30 segundos. A pontuação de 0 a 100 do DB Optimizer informa qual das cinco métricas está causando problemas.
• Autoload saudável fica abaixo de aproximadamente 800KB, e wp_options abaixo de 3 a 5MB em um site típico. Acima desses valores, vale a pena agir.
• As revisões não têm limite por padrão, então essa métrica se preenche sozinha, a menos que você defina WP_POST_REVISIONS em wp-config.php.

Sumário

O que uma Verificação de Integridade do Banco de Dados do WordPress Abrange?

Uma verificação de integridade do banco de dados não é uma verificação de tamanho. O tamanho por si só não diz quase nada.

Um banco de dados WooCommerce de 500MB com dez anos de pedidos reais pode estar em melhor forma do que um blog de 60MB onde três quartos das linhas são revisões de posts.

O que você está medindo é a composição. Quanta parte deste banco de dados é conteúdo que você sentiria falta, e quanta parte é resíduo?

Aqui está o que uma verificação de integridade real cobre:

• Tamanho total e taxa de crescimento. O número importa menos do que a rapidez com que ele está subindo entre as verificações. Um banco de dados que cresceu 40% em um trimestre tranquilo está dizendo algo.
• Sobrecarga da tabela. Espaço deixado para trás por linhas excluídas e que o MySQL ainda não recuperou. É ar morto dentro da tabela.
• Tamanho do autoload. As opções que o WordPress carrega em cada solicitação de página, quer a página precise delas ou não. Esta é a métrica que afeta mais diretamente o desempenho.
• Lixo nas linhas. Revisões de posts, rascunhos automáticos, posts na lixeira, comentários de spam, transientes expirados, pingbacks, trackbacks e respostas oEmbed em cache. Tudo isso se acumula por padrão e nada disso se limpa sozinho.
• Tabelas e metadados órfãos. Ao excluir um plugin, ele pode deixar para trás tabelas e linhas.

O Que Você Precisa Antes de Começar

A maior parte disso é executada no seu painel gratuitamente. Aqui está a lista completa:

• Acesso administrativo ao WordPress. A Saúde do Site e o DB Optimizer ficam no seu painel.
• Um backup atual, feito com o Duplicator. Um backup apenas do banco de dados cobre este trabalho e termina em uma fração do tempo que um backup completo leva.
• DB Optimizer, se você quiser uma verificação aprofundada do banco de dados. É gratuito com o Duplicator Pro.
• phpMyAdmin ou acesso ao banco de dados da hospedagem. Opcional, e apenas para a rota manual na Etapa 4.

Como Executar uma Verificação de Integridade do Banco de Dados do WordPress

Veja como verificar a integridade do seu banco de dados WordPress:

• Passo 1: Obtenha sua linha de base de tamanho de banco de dados em Integridade do Site. Gratuito, sem plugin, cerca de 30 segundos, e ele fornece o único número que você acompanhará ao longo do tempo.
• Passo 2: Pontue seu banco de dados com o DB Optimizer. Transforma um valor de tamanho em uma pontuação de 0 a 100 com cinco barras, para que você possa ver qual parte do banco de dados é o problema.
• Passo 3: Leia as cinco métricas e descubra o que está diminuindo a pontuação. Os limites que separam uma leitura normal de uma que vale a pena agir, métrica por métrica.
• Passo 4: Audite suas tabelas quanto a sobrecarga e órfãos. Encontra as tabelas específicas que carregam espaço morto, além dos restos de plugins que você removeu.
• Passo 5: Faça backup antes de excluir qualquer coisa. O passo que transforma uma limpeza ruim em um pequeno inconveniente.
• Passo 6: Limpe o que é seguro e, em seguida, reavalie. Remove o lixo por trás de uma pré-visualização e uma janela de retenção, e então fornece um número "depois" para comparar com sua linha de base.

Passo 1: Obtenha a Linha de Base do Tamanho do Seu Banco de Dados na Integridade do Site

Comece aqui, mesmo que você esteja planejando instalar um plugin em um minuto. Este passo não custa nada, leva cerca de 30 segundos e produz o número que você comparará toda vez que executar isso novamente.

Vá para Ferramentas » Integridade do Site no seu painel, em seguida, clique na aba Info no topo.

Expanda a seção Diretórios e Tamanhos. Você verá o tamanho do seu banco de dados em MB.

Anote com a data de hoje.

Enquanto você está nesta tela, expanda a seção Banco de Dados mais abaixo na página. Ela mostra a extensão (MySQL ou MariaDB), a versão do servidor, a versão do cliente e o conjunto de caracteres.

Isso é tudo que o Integridade do Site sabe sobre o seu banco de dados.

A aba Status não avalia revisões, sobrecarga de tabelas, propriedade de tabelas de plugins ou inchaço geral do banco de dados. No entanto, ela avalia opções autoloaded em versões suportadas do WordPress. Ela solicitará que você limpe dados autoloaded se eles forem sinalizados.

Passo 2: Pontue Seu Banco de Dados com o DB Optimizer

Um valor de tamanho diz que o banco de dados é grande. Ele não diz por quê. Para isso, você precisa de algo que leia o que está dentro, que é o que o DB Optimizer faz.

Instale o DB Optimizer e abra-o a partir do seu painel. A tela principal exibe uma pontuação de saúde entre 0 e 100, e abaixo dela, cinco barras de progresso codificadas por cores:

• Sobrecarga de tabelas
• Transientes
• Revisões
• Tamanho do autoload
• Itens da lixeira

Leia as barras, não apenas o número. Um 62 causado por revisões é um conserto de dez minutos. Um 62 causado pelo tamanho do autoload é uma tarde mais longa, por razões que entrarei no Passo 3.

O botão Atualizar Pontuação reavalia sob demanda. Use-o após qualquer alteração para que você nunca esteja lendo um número desatualizado.

Passo 3: Leia as Cinco Métricas e Descubra o Que Está Diminuindo a Pontuação

Uma pontuação baixa de saúde do banco de dados não significa muito até que você saiba como é o normal para essa métrica. Estes são os números contra os quais eu julgo:

Métrica	Saudável	Vale a atenção
Tamanho do autoload	Abaixo de aproximadamente 800KB	1MB e acima
Tabela wp_options	Abaixo de 3 a 5MB em um site típico	10MB ou mais
Revisões de posts	Limitado a 3 a 5 por post	Ilimitado, que é o padrão
Sobrecarga de tabelas	Próximo de zero após uma execução de otimização	Crescendo entre cada verificação
Lixo e spam	Esvaziado em uma programação	Meses de acúmulo

Autoload, revisões, sobrecarga e lixo recebem sua própria barra na tela de pontuação. A linha wp_options é uma que você lerá na visualização de tabelas na Etapa 4.

Veja o que cada métrica mede e o que fazer quando estiver fora do intervalo.

Tamanho do autoload é o conjunto de opções que o WordPress carrega na memória a cada solicitação de página, incluindo as solicitações que nunca as usam. Abaixo de aproximadamente 800KB está bom. A partir de 1MB, você paga esse custo em cada acesso, e a causa geralmente são alguns plugins armazenando grandes arrays em wp_options.

Revisões são o motivo mais comum para uma pontuação ruim e a coisa mais fácil de consertar. O WordPress salva um número ilimitado por padrão. Cada salvamento e cada salvamento automático de cada post, mantido para sempre. Em um site com algumas centenas de posts e mais de um editor, as revisões rotineiramente superam as linhas de conteúdo real.

Transientes são valores em cache com uma data de expiração. O WordPress não limpa de forma confiável os expirados, então eles se acumulam. Removê-los é seguro, e qualquer coisa que ainda seja necessária se regenera sozinha.

Itens de lixo cobrem posts e páginas no lixo, mais comentários de spam. O WordPress esvazia o lixo após 30 dias por padrão. Comentários de spam permanecem até que algo os remova.

Sobrecarga da tabela é o espaço que as linhas excluídas deixam para trás. Excluir mil revisões não encolhe a tabela por si só. Deixa mil lacunas, e uma execução de otimização é o que reconstrói a tabela e as recupera.

Passo 4: Audite Suas Tabelas em Busca de Sobrecarga e Órfãs

A pontuação diz que tipo de lixo você tem. A visualização de tabelas diz onde ele está, o que importa quando uma tabela se mostra responsável pela maior parte do problema.

No Otimizador de Banco de Dados, abra a visualização de tabelas. Ela lista cada tabela em seu banco de dados com seu tamanho e sua sobrecarga. Você pode otimizar e reparar uma tabela ou o banco de dados inteiro.

Ordene por tamanho e leia seus cinco primeiros. Em um site típico, você esperaria wp_posts, wp_postmeta e wp_options no topo. Se wp_options estiver lá em cima, compare-o com o benchmark de 3 a 5MB da Etapa 3.

Existe uma rota manual que mostra a mesma coisa se você já tem acesso ao banco de dados. Abra o phpMyAdmin no seu painel de hospedagem, selecione seu banco de dados e ordene a lista de tabelas pela coluna Tamanho.

Pule isso se o phpMyAdmin não for algo que você normalmente usa, porque a visualização de plugins cobre isso.

Agora procure por tabelas que não pertencem mais a nada.

Tabelas órfãs geralmente carregam o prefixo da sua tabela mais o nome de um plugin, deixado por um plugin que você excluiu meses ou anos atrás. O WordPress remove arquivos de plugin ao excluir. Raramente remove tabelas de plugin, porque o autor do plugin tem que escrever essa rotina de limpeza, e muitos nunca o fazem.

Não exclua uma tabela que você não consegue identificar. Pesquise o nome da tabela, verifique-o em relação aos plugins que você removeu e, se não conseguir localizá-la com confiança, deixe-a em paz. Uma tabela sobrando custa alguns MB. Excluir uma ativa custa um restore.

Passo 5: Faça Backup Antes de Excluir Qualquer Coisa

A partir daqui, você estará excluindo linhas do banco de dados, e é por isso que você precisa de um backup.

Crie um backup do seu site. Um backup da semana passada não cobre uma alteração que você está fazendo hoje, e todo o valor de um ponto de restauração é que ele fica imediatamente antes da ação arriscada.

Um backup apenas do banco de dados é suficiente para este trabalho. O Duplicator Pro pode criar um que ignora completamente seus arquivos, terminando em uma fração do tempo que um backup completo leva.

Se você preferir a reversão mais rápida possível, crie um backup completo do site com um ponto de recuperação em vez disso.

Com o Duplicator Pro instalado junto com o DB Optimizer, você receberá um aviso de status de backup na tela de limpeza antes que qualquer coisa seja executada. Ele está verificando exatamente isso.

Etapa 6: Limpe o que é seguro e, em seguida, reavalie

Com um backup em vigor, a limpeza é a parte menos emocionante de todo o processo.

Abra a guia Limpeza.

Selecione o que você deseja remover e, em seguida, leia a prévia antes de prosseguir. Ela mostra contagens de itens e o espaço que você recuperaria, para que você nunca confirme um número que não viu.

Mais uma coisa para verificar antes de limpar: a configuração de retenção. O padrão protege qualquer coisa dos últimos 7 dias, e você pode ajustá-la. Encontre esse valor nas configurações do DB Optimizer.

Quando estiver pronto, clique em Limpar Itens Selecionados e confirme.

Quando terminar, clique em Atualizar Pontuação e anote os novos números ao lado dos antigos. Essa comparação é o motivo pelo qual você fez uma linha de base na Etapa 1.

Para as correções que vivem fora de uma execução de limpeza (limitar revisões, limpar tags não utilizadas, desativar pingbacks), o guia completo está em nosso manual sobre como otimizar seu banco de dados WordPress.

Com Que Frequência Você Deve Executar uma Verificação de Integridade do Banco de Dados do WordPress?

O inchaço do banco de dados volta. Este não é um problema que você resolve uma vez; é um que você mantém em um nível gerenciável.

A programação de limpeza correta depende de quanto seu site está fazendo no dia a dia.

Aqui está a programação que uso:

• Limpezas mensais para blogs ativos, lojas WooCommerce e sites de associação. Qualquer coisa com publicações regulares, pedidos ou atividade do usuário está gerando linhas todos os dias.
• Limpezas trimestrais para um site estático que é editado algumas vezes por ano. Vá além disso, e você perde o sinal da taxa de crescimento porque não terá leituras suficientes para comparar.

Alguns momentos valem uma verificação fora do cronograma. Estes são os que sempre olho primeiro:

• Antes de uma migração. Um banco de dados inchado torna cada parte de uma mudança mais lenta e dá ao importador mais chances de falhar por tempo limite.
• Após a remoção de plugins. É quando tabelas órfãs podem aparecer.
• Após uma importação em massa. Grandes importações geram revisões e linhas de postmeta em volume.
• Antes de um lançamento ou uma venda. O tráfego amplifica qualquer ineficiência que você já esteja carregando.

Solução de Problemas de uma Verificação de Integridade do Banco de Dados do WordPress

A maioria desses problemas aparece em sites maiores. Aqui estão os problemas que vejo com mais frequência e o que fazer sobre cada um.

Diretórios e Tamanhos Apenas Dizem "Carregando" e Nunca Terminam

O que você vê: A seção Diretórios e Tamanhos em Verificação de Integridade gira indefinidamente, e nenhum tamanho de banco de dados aparece.

Por que acontece: O WordPress calcula esses números em tempo real percorrendo seus diretórios. Em um site com uma pasta de uploads grande, isso pode levar mais tempo do que a solicitação permite. Ele também depende de requisições de loopback, que alguns hosts e plugins de segurança bloqueiam.

Como corrigir: Dê alguns minutos primeiro se o site for grande. Se ainda não resolver, verifique o teste de requisição de loopback na aba Status. Esse é geralmente o culpado, e seu host pode explicar em uma única resposta. Você também pode ver o tamanho do banco de dados diretamente no painel de controle da sua hospedagem ou no phpMyAdmin.

Por que o Tamanho do Banco de Dados da Verificação de Integridade Não Corresponde ao Relatado pelo Seu Host?

O que você vê: A Verificação de Integridade diz 180MB. Seu painel de hospedagem diz 400MB.

Por que acontece: Eles estão contando coisas diferentes. A Verificação de Integridade relata dados mais índices. Hosts frequentemente relatam o espaço em disco alocado, que inclui espaço que seu banco de dados ainda não está usando. Alguns deles incluem logs binários ou backups armazenados.

Como corrigir: Escolha uma fonte e mantenha-a. O número absoluto importa muito menos do que observar a mesma medição mudar ao longo do tempo, então a consistência supera a precisão aqui.

Você Encontrou Tabelas que Não Reconhece

O que você vê: Tabelas em seu banco de dados com nomes que você não consegue identificar.

Por que acontece: Plugins criam suas próprias tabelas, e a maioria não as remove ao desinstalar. Alguns hosts e ferramentas de segurança também adicionam tabelas. Algumas pertencerão a plugins que ainda estão ativos sob um nome que você não adivinharia de fora.

Como corrigir: Pesquise o nome exato da tabela antes de fazer qualquer coisa com ela. Verifique-a em relação aos plugins que você excluiu. Se você puder identificá-la como um resíduo e tiver o backup da Etapa 5, excluí-la é razoável. Se não puder identificá-la, deixe-a. Nunca exclua uma tabela para descobrir o que ela fazia.

Perguntas Frequentes (FAQs)

Verifique os Números Antes que Seu Site Diga Que Algo Está Errado

Agora você tem algo que a maioria dos sites não tem: uma linha de base datada, um veredito sobre cinco métricas e uma data para verificá-las novamente. Uma verificação de saúde do banco de dados do WordPress não é um trabalho difícil.

A leitura que mais importa é a que você fará da próxima vez. Um banco de dados que cresceu 15% durante um trimestre movimentado está bom. O mesmo crescimento em um site que você mal tocou significa que algo está escrevendo linhas que você não conhece. Vale a pena investigar antes que cause problemas como timeouts de backup.

Duplicator Pro permite agendar backups, armazenar dados na nuvem e reverter seu site se ocorrer um erro. Ao fazer o upgrade para o Pro, você receberá o DB Optimizer gratuitamente!

Se este tutorial ajudou, estes guias também valem a pena ser marcados.

• Como Otimizar Seu Banco de Dados WordPress: Obtenha um Site Rápido em 10 Passos.
• Limpeza do Banco de Dados do WordPress: Um Guia para Iniciantes para Remover o Lixo
• Como Corrigir um Banco de Dados Lento do WordPress: Um Checklist de 4 Passos
• 7 sinais de aviso do banco de dados do WordPress que a maioria dos proprietários de sites ignora
• O Melhor Plugin de Otimização de Banco de Dados WordPress para 2026 (Mais 4 Alternativas)
• Como Atualizar o Banco de Dados do WordPress (+ Corrigir o Loop de "Atualização Necessária")