Banco de dados WordPress pesado: como limpar revisões e transients sem quebrar o site

Um banco de dados WordPress pesado pode deixar o painel mais lento, aumentar o tamanho do backup, dificultar migrações e, em alguns casos, contribuir para páginas demorando mais para responder.

Mas “limpar banco de dados WordPress” não significa apagar tudo que parece antigo. O banco guarda posts, páginas, usuários, comentários, pedidos, configurações de plugins, dados de formulário, menus, produtos, sessões, transients, revisões e outras informações essenciais para o site funcionar.

A regra é simples: antes de limpar, saiba o que será removido, tenha um backup restaurável e valide o site depois.

Se a sua meta é performance, trate este tutorial como uma parte do diagnóstico. Para uma visão mais ampla, veja também o checklist de como melhorar a velocidade de um WordPress lento. Aqui o foco é especificamente banco de dados: revisões, transients, lixeira, wp_options, autoload e otimização segura.

Antes de qualquer limpeza: faça backup completo e restaurável do site, incluindo arquivos e banco de dados. Se possível, teste primeiro em staging. Isso é ainda mais importante em WooCommerce, áreas de membros, cursos, assinaturas, formulários, sites com leads recentes ou qualquer ambiente em que perda de dados possa causar prejuízo real.

Banco de dados WordPress pesado é sempre a causa da lentidão?

Não necessariamente.

Um banco grande pode atrapalhar backup, migração, restauração, busca, painel administrativo e algumas consultas. Mas a lentidão do WordPress também pode vir de hospedagem limitada, plugins pesados, tema mal otimizado, imagens grandes, cache ausente, chamadas externas lentas, PHP antigo, falta de object cache ou excesso de scripts.

Por isso, não trate limpeza de banco como solução mágica. Ela é uma etapa de manutenção.

Em muitos sites, limpar revisões antigas, transients expirados e lixo acumulado ajuda a reduzir peso e organizar a base. Em outros, o ganho de velocidade só aparece quando você também revisa cache, plugins, hospedagem e consultas lentas.

Se você ainda não investigou plugins, complemente com o guia sobre como descobrir plugins lentos no WordPress. Se o site ainda não usa cache corretamente, veja também como configurar cache no WordPress.

O que costuma deixar o banco de dados WordPress pesado?

O banco cresce naturalmente conforme o site é usado. Isso não é problema por si só. O alerta aparece quando há acúmulo de dados temporários, órfãos, antigos ou carregados sem necessidade.

Alguns exemplos comuns:

Tipo de dado	Onde costuma aparecer	Risco ao limpar
Revisões de posts e páginas	Tabelas de posts e metadados	Baixo a médio, se você não precisa recuperar versões antigas
Rascunhos automáticos	Posts/autosaves	Baixo a médio
Posts e páginas na lixeira	Conteúdo marcado como lixeira	Baixo, se você conferiu antes
Comentários spam e lixeira	Comentários	Baixo, se a moderação está revisada
Transients expirados	Geralmente wp_options, mas pode variar com object cache	Baixo, em geral, quando são expirados
Transients ativos	Banco ou object cache	Médio, pois podem causar recálculo ou instabilidade temporária em plugins
Opções autoload grandes	wp_options	Médio a alto, depende do plugin/tema responsável
Tabelas de plugins removidos	Banco de dados	Médio a alto, se você não sabe a origem
Dados de WooCommerce, LMS, membros e formulários	Tabelas próprias ou metadados	Alto, pois podem ser pedidos, alunos, assinaturas ou leads

A limpeza segura começa separando essas categorias. O que é lixo para um site pode ser dado crítico para outro.

O que geralmente pode ser limpo com mais segurança?

Mesmo os itens mais seguros exigem backup. Ainda assim, alguns dados costumam ser melhores candidatos para uma primeira limpeza.

1. Revisões antigas de posts e páginas

O WordPress salva revisões para permitir recuperar versões anteriores de um conteúdo. Isso é útil, especialmente em sites com fluxo editorial.

O problema é o acúmulo. Um post antigo pode ter dezenas ou centenas de revisões, principalmente se passou por muitas edições, construtores visuais ou ajustes frequentes.

Você pode considerar remover revisões antigas quando:

• o conteúdo já está publicado e estável;
• você não precisa recuperar versões muito antigas;
• existe backup completo;
• a limpeza será feita por ferramenta confiável, com prévia ou seleção;
• o site foi testado depois.

Evite apagar todas as revisões sem pensar. Em sites editoriais, manter algumas revisões recentes pode ser útil.

2. Conteúdo na lixeira

Posts, páginas e comentários enviados para a lixeira continuam no banco até serem removidos definitivamente.

Antes de limpar:

• confira se não há páginas importantes na lixeira;
• verifique se não existe conteúdo que alguém pretende recuperar;
• cuidado em sites com vários editores.

Depois disso, esvaziar lixeira costuma ser uma limpeza simples.

3. Comentários spam e comentários na lixeira

Comentários de spam podem acumular bastante volume em sites antigos.

É razoável limpar quando:

• você já revisou a fila;
• não há comentários legítimos marcados por engano;
• o plugin antispam está funcionando;
• você tem backup.

4. Transients expirados

Transients são dados temporários usados por WordPress, temas e plugins para guardar cache por um período. A documentação oficial do WordPress explica que transients têm um tempo máximo de expiração, mas podem desaparecer antes desse prazo, especialmente quando há cache externo.

Em geral, transients expirados são bons candidatos para limpeza, porque já não deveriam ser usados como dados permanentes.

Mesmo assim, limpe com cuidado. Em alguns sites, apagar transients pode causar recálculo temporário de caches, chamadas externas ou telas demorando um pouco mais na primeira visita após a limpeza.

O que exige mais cuidado?

Alguns itens parecem “lixo”, mas podem ser essenciais.

1. Opções em wp_options

A tabela wp_options guarda configurações do WordPress, plugins e temas. Ela pode conter desde o nome do site até configurações de cache, construtor de páginas, gateways, formulários, segurança, licenças e integrações.

Por isso, “limpar wp_options” é uma expressão perigosa quando usada sem contexto.

O ponto de atenção não é apenas o tamanho da tabela. Um problema comum é o autoload: algumas opções são carregadas automaticamente em cada requisição. Se há opções autoload muito grandes ou órfãs, o site pode carregar dados demais o tempo todo.

Mas a solução não é apagar opções aleatórias.

Antes de remover qualquer opção:

1. identifique o nome da opção;
2. descubra qual plugin, tema ou recurso criou aquilo;
3. confirme se o plugin ainda está ativo;
4. veja se existe ferramenta oficial do plugin para limpar dados;
5. exporte o item ou a tabela envolvida, quando aplicável;
6. teste em staging;
7. tenha backup do banco;
8. valide o site depois.

Se você não sabe de onde veio uma opção, não apague.

2. Tabelas deixadas por plugins antigos

Muitos plugins criam tabelas próprias. Quando você desinstala o plugin, algumas tabelas podem permanecer para preservar dados caso o plugin seja reinstalado.

Isso pode ser bom ou ruim. Uma tabela antiga pode ser lixo real, mas também pode guardar pedidos, logs, formulários, estatísticas, afiliados, aulas, membros ou configurações históricas.

Antes de excluir qualquer tabela:

• verifique o prefixo e o nome;
• procure qual plugin criou a tabela;
• confira se o plugin ainda está ativo;
• veja se há opção de desinstalação completa dentro do plugin;
• exporte a tabela antes;
• teste em staging.

3. Dados de WooCommerce, membros, cursos e formulários

Aqui o cuidado deve ser máximo.

Em lojas e sites transacionais, o banco pode ter:

• pedidos;
• carrinhos e sessões;
• clientes;
• assinaturas;
• cupons;
• produtos;
• logs de pagamento;
• leads;
• inscrições;
• histórico de aluno;
• permissões de acesso.

Apagar “dados antigos” sem entender a regra de negócio pode causar perda real. Nesses casos, limpeza deve ser planejada com backup, staging e, de preferência, suporte técnico.

O que não fazer ao limpar banco de dados WordPress

Antes do passo a passo, vale deixar claro o que evitar.

Não faça isto:

• copiar e colar comandos SQL encontrados na internet;
• rodar DELETE manual em produção sem consulta prévia, export e backup;
• apagar tabelas só porque têm prefixo de plugin antigo;
• limpar wp_options por tamanho sem saber a origem das opções;
• apagar transients ativos em site crítico sem saber o impacto;
• rodar várias limpezas de uma vez sem medir o antes e depois;
• otimizar banco durante horário de pico;
• testar em produção se existe staging disponível;
• restaurar backup antigo em WooCommerce sem considerar pedidos recentes.

Banco de dados é uma parte central do WordPress. Um clique errado pode ser mais grave do que desativar um plugin.

Pré-requisitos antes de começar

Antes de limpar banco de dados WordPress, tenha:

1. acesso de administrador ao WordPress;
2. acesso ao painel da hospedagem;
3. backup completo de arquivos e banco de dados;
4. confirmação de que o backup pode ser restaurado;
5. staging, principalmente em sites críticos;
6. lista de plugins ativos;
7. informação sobre WooCommerce, membros, cursos, formulários ou integrações;
8. horário de menor tráfego para mudanças em produção;
9. plano de reversão;
10. checklist do que testar após a limpeza.

Se você ainda não tem rotina de cópia, comece pelo guia de backup WordPress em nuvem. Para mudanças mais sensíveis, use também um ambiente de staging WordPress.

Passo a passo seguro para limpar banco de dados WordPress

1. Meça o estado atual

Antes de mexer, registre a situação atual:

• tamanho total do banco;
• tabelas maiores;
• tamanho de wp_posts, wp_postmeta, wp_options, comentários e tabelas de plugins;
• número aproximado de revisões;
• volume de comentários spam/lixeira;
• se há muitas opções autoload;
• velocidade percebida no painel;
• tempo de backup e restauração, se isso for um problema.

Você pode obter parte dessas informações pelo painel da hospedagem, phpMyAdmin, ferramenta de manutenção ou plugin de diagnóstico. Não é necessário executar SQL manual para um primeiro diagnóstico se você não tem segurança técnica.

2. Faça backup completo e restaurável

Backup não é formalidade. É o que permite voltar atrás.

O backup deve incluir:

• banco de dados;
• arquivos do WordPress;
• wp-content;
• uploads;
• plugins;
• tema;
• arquivos de configuração importantes.

Além de criar a cópia, confirme onde ela está, como restaurar e se ela é recente. Em sites com vendas, leads ou membros, cuidado com restauração: voltar um backup antigo pode apagar dados novos.

3. Teste em staging sempre que possível

Se a hospedagem oferece staging, use.

Faça a limpeza na cópia de teste primeiro. Depois valide:

• páginas principais;
• posts;
• busca;
• painel administrativo;
• login;
• formulários;
• checkout;
• área do cliente;
• cache;
• integrações importantes.

Staging não substitui backup, mas reduz bastante o risco de descobrir o erro no site publicado.

4. Limpe por etapas pequenas

Não faça tudo de uma vez.

Uma ordem mais segura é:

1. lixeira de posts/páginas;
2. spam e comentários na lixeira;
3. revisões antigas, mantendo uma quantidade razoável quando fizer sentido;
4. rascunhos automáticos antigos;
5. transients expirados;
6. investigação de autoload em wp_options;
7. análise de tabelas órfãs;
8. otimização de tabelas, se fizer sentido no ambiente.

Depois de cada etapa, confira o site. Assim, se algo quebrar, você sabe onde procurar.

5. Use ferramentas com prévia quando possível

Para público não técnico, o caminho mais seguro costuma ser usar uma ferramenta de manutenção confiável que mostre o que será removido antes de apagar.

Procure recursos como:

• relatório antes da limpeza;
• seleção por categoria;
• limpeza de revisões separada de transients;
• opção de manter revisões recentes;
• compatibilidade com multisite, se for o caso;
• histórico ou log da limpeza;
• recomendação explícita de backup.

Evite ferramenta que promete “limpar tudo” sem mostrar detalhes.

Como limpar revisões WordPress com segurança

Revisões são úteis. Elas permitem comparar versões e recuperar conteúdo anterior. A limpeza deve equilibrar espaço e segurança editorial.

Quando limpar revisões

Considere limpar quando:

• o site tem muitos posts antigos;
• há páginas com dezenas de revisões;
• o banco cresceu muito por histórico editorial;
• você já tem backup;
• os conteúdos estão estáveis;
• você pode manter algumas revisões recentes.

Quando não limpar revisões

Evite limpar quando:

• há disputa editorial ou necessidade de auditoria;
• o conteúdo está em revisão ativa;
• vários editores trabalham no site;
• você não tem backup;
• não sabe se precisará recuperar uma versão anterior.

Limitar revisões futuras

A documentação do WordPress permite limitar o número de revisões futuras com a constante WP_POST_REVISIONS no wp-config.php.

Exemplo conceitual:

define( 'WP_POST_REVISIONS', 5 );

Isso indica que o WordPress deve manter até 5 revisões por post/página, conforme a configuração e o comportamento do ambiente.

Use com cuidado:

• edite wp-config.php somente se souber reverter;
• faça backup antes;
• teste em staging;
• não desative revisões em sites editoriais sem alinhar com a equipe;
• lembre que isso controla revisões futuras, não é uma limpeza completa do histórico antigo.

Para a maioria dos sites, limitar revisões é mais seguro do que desativá-las totalmente.

Como lidar com transients WordPress

Transients são dados temporários. Plugins, temas e o próprio WordPress podem usá-los para guardar resultados de consultas, respostas de API e dados que não precisam ser recalculados a todo momento.

A documentação oficial destaca um ponto importante: transients têm tempo máximo de vida, mas podem desaparecer antes. Portanto, código bem feito não deve depender de transient como se fosse dado permanente.

Posso apagar transients expirados?

Em geral, sim, desde que você tenha backup e use ferramenta adequada. Transients expirados já passaram do tempo previsto.

A limpeza pode:

• reduzir linhas antigas no banco;
• resolver acúmulo de dados temporários;
• ajudar em manutenção;
• forçar plugins a recalcular alguns caches.

Depois da limpeza, a primeira visita a algumas telas pode demorar um pouco mais, porque certos dados serão recriados.

Posso apagar todos os transients?

Depende.

Apagar todos os transients pode ser útil em troubleshooting de cache, mas não deve ser a recomendação padrão em site crítico. Alguns plugins podem precisar regenerar dados, refazer chamadas externas ou reconstruir cache.

Se for necessário, prefira:

1. fazer em staging primeiro;
2. escolher horário de menor tráfego;
3. limpar cache de página/object cache depois, se aplicável;
4. testar páginas críticas;
5. monitorar erros.

E quando há Redis, Memcached ou object cache?

Com object cache externo, nem todo transient fica gravado no banco. Alguns podem estar em memória. Isso muda o diagnóstico.

Se o site usa Redis, Memcached, cache gerenciado da hospedagem ou plugin de object cache, alinhe a limpeza com a ferramenta de cache usada. Limpar o banco pode não limpar o cache em memória; limpar o cache em memória pode exigir outro procedimento.

Nota avançada sobre WP-CLI

O WP-CLI tem comandos para transients, como wp transient delete --expired para apagar transients expirados e wp transient delete --all para apagar todos. Para a maioria dos administradores, isso deve ser tratado como caminho avançado, executado por quem sabe operar o ambiente, fazer rollback e validar o resultado.

Se for usar WP-CLI, prefira começar por transients expirados e evite --all em produção sem teste prévio, especialmente em lojas, áreas logadas ou sites com tráfego alto.

Como investigar wp_options e autoload sem sair apagando

A tabela wp_options é uma das mais importantes do WordPress. Ela guarda configurações do core, tema e plugins.

Quando alguém diz “preciso limpar wp_options”, normalmente o problema real é um destes:

• opções antigas de plugin removido;
• opções muito grandes;
• opções autoload carregadas em toda página;
• transients acumulados;
• configurações duplicadas;
• plugin salvando dados demais onde não deveria.

O que é autoload?

De forma simplificada, autoload indica que determinada opção pode ser carregada automaticamente pelo WordPress. Isso é útil para configurações usadas o tempo todo, mas ruim para dados grandes que não precisam aparecer em todas as requisições.

Se muitas opções grandes são carregadas automaticamente, o site pode consumir mais memória e demorar mais para responder.

Como agir com segurança

Em vez de apagar, investigue:

1. quais opções são maiores;
2. quais têm autoload ativo;
3. qual plugin/tema criou cada opção;
4. se o plugin ainda está instalado;
5. se existe recurso oficial para limpar dados;
6. se a opção é configuração ativa ou resíduo antigo.

Se uma opção parece órfã, exporte antes e teste em staging. Nunca apague em produção sem saber o impacto.

Evite também orientar usuários leigos a alterar opções diretamente por telas técnicas ou pelo banco. Uma opção aparentemente inofensiva pode controlar URL do site, plugins ativos, widgets, cache, pagamentos ou integrações.

Otimizar banco WordPress é o mesmo que limpar banco?

Não.

“Limpar” é remover dados desnecessários, como revisões antigas, spam, lixeira ou transients expirados.

“Otimizar” geralmente significa reorganizar tabelas, recuperar espaço interno ou executar uma operação do banco de dados, como OPTIMIZE TABLE, dependendo do MySQL/MariaDB, da hospedagem e do mecanismo de armazenamento.

O WP-CLI, por exemplo, tem o comando wp db optimize, que usa as credenciais do wp-config.php para otimizar o banco. Mas isso é um procedimento avançado. Ele não decide o que pode ser apagado e não resolve, sozinho, plugins fazendo consultas ruins.

Use otimização com cuidado quando:

• há backup recente;
• você entende o ambiente;
• a hospedagem permite esse tipo de operação;
• o site não está em horário de pico;
• você consegue reverter se algo der errado.

Em hospedagens gerenciadas, pode ser melhor pedir orientação ao suporte antes.

Checklist pós-limpeza: o que testar

Depois de limpar banco de dados WordPress, não feche a ferramenta e vá embora. Teste o site.

Confira:

• home;
• posts e páginas importantes;
• menu;
• busca interna;
• painel do WordPress;
• editor de posts;
• upload de mídia;
• login e logout;
• formulário de contato;
• páginas com shortcode ou construtor visual;
• cache de página;
• versão mobile;
• páginas com scripts externos;
• sitemap, se aplicável.

Se houver WooCommerce, teste também:

• página de produto;
• carrinho;
• checkout;
• cupom;
• cálculo de frete;
• pagamento em modo seguro/teste quando possível;
• e-mails transacionais;
• área “minha conta”.

Se houver área de membros, cursos ou assinaturas, teste:

• login de usuário comum;
• acesso a conteúdo protegido;
• progresso de aulas;
• permissões;
• renovação ou cobrança, quando aplicável.

Quando chamar a hospedagem ou um desenvolvedor

Chame suporte técnico se:

• o banco é muito grande e você não sabe quais tabelas pesam;
• há WooCommerce, membros, cursos ou dados financeiros;
• o site tem erros depois da limpeza;
• você precisa mexer em wp_options ou tabelas órfãs;
• há suspeita de malware criando dados;
• a limpeza envolve SQL manual;
• o backup não foi testado;
• o site não pode ficar fora do ar;
• a hospedagem tem limites de banco, CPU ou memória.

Também peça ajuda se o painel está lento, mas o banco não parece grande. Nesse caso, o gargalo pode estar em plugin, hospedagem, cache, PHP, consultas específicas ou chamadas externas.

Resumo prático: o que limpar primeiro

Se você quer uma ordem segura, siga esta lógica:

1. Faça backup completo e confirme restauração.
2. Use staging se o site for importante.
3. Esvazie lixeira revisada.
4. Remova spam revisado.
5. Limpe revisões antigas mantendo algumas recentes.
6. Remova transients expirados.
7. Valide o site.
8. Só depois investigue wp_options, autoload e tabelas órfãs.
9. Evite SQL manual sem técnico.
10. Otimize tabelas apenas se fizer sentido no ambiente.

Conclusão

Limpar banco de dados WordPress pode ser uma boa prática de manutenção, especialmente em sites antigos, blogs com muitas revisões, instalações com transients acumulados ou ambientes que passaram por muitos plugins ao longo do tempo.

Mas a limpeza precisa ser seletiva. Revisões, lixeira e transients expirados costumam ser os primeiros candidatos. Já wp_options, autoload, tabelas de plugins, WooCommerce, membros e formulários exigem muito mais cuidado.

Antes de apagar qualquer coisa, faça backup restaurável, teste em staging quando possível e limpe em etapas pequenas. Se a sua meta é performance, combine essa manutenção com diagnóstico de cache, hospedagem, plugins e consultas lentas.

A melhor limpeza não é a mais agressiva. É aquela que reduz peso sem colocar o site em risco.