Banco de Dados do WordPress: Como Limpar, Otimizar e Devolver Velocidade ao Site

Todo mundo cuida das imagens, dos plugins e do tema, mas quase ninguém olha para o banco de dados do WordPress — e é justamente lá que o site vai engordando em silêncio. O banco é a memória do site: guarda cada post, cada comentário, cada configuração e cada rastro que os plugins deixam para trás. Com o tempo, ele acumula uma quantidade impressionante de lixo que ninguém pediu para guardar: dezenas de versões antigas de cada texto, dados temporários que já expiraram, comentários de spam, tabelas de plugins que você desinstalou meses atrás. Nada disso aparece na tela, mas tudo isso pesa.

O sintoma é conhecido: o painel administrativo fica lento, salvar um post demora, as buscas internas arrastam, e o site parece cansado sem motivo aparente. Você troca de plugin de cache, otimiza imagem, e mesmo assim o WordPress continua pesado — porque o problema está embaixo, no banco inchado que precisa vasculhar cada vez mais linhas para responder a cada consulta. Este guia é sobre entrar nessa camada com segurança: o que exatamente incha o banco, como limpar sem quebrar nada, o que significa "otimizar" uma tabela, e — igualmente importante — o que você nunca deve tocar. E antes de tudo, a regra de ouro: backup primeiro, sempre.

Por que o banco incha (e por que isso deixa o site lento)#

O WordPress guarda praticamente tudo em tabelas do banco de dados. Cada consulta que ele faz para montar uma página precisa percorrer essas tabelas. Quanto mais linhas inúteis houver, mais o banco trabalha para achar o que importa — como procurar um documento numa gaveta que ninguém organiza há anos. O acúmulo não é um problema de espaço em disco (o banco costuma ser pequeno); é um problema de eficiência de leitura.

O inchaço vem de várias fontes que trabalham silenciosamente, todo dia, sem você perceber. Entender de onde vem o lixo é o primeiro passo para limpá-lo com critério, em vez de sair apagando coisas às cegas.

• Revisões de post. Cada vez que você salva um texto, o WordPress guarda a versão anterior como revisão. Um artigo muito editado pode ter dezenas de cópias, cada uma ocupando espaço e sendo indexada.
• Rascunhos automáticos e itens na lixeira. O salvamento automático e os posts/comentários "excluídos" que ainda estão na lixeira continuam no banco até serem apagados de verdade.
• Transients expirados. Plugins guardam dados temporários (transients) com prazo de validade. Quando expiram, muitos não se limpam sozinhos e ficam acumulando.
• Spam e comentários rejeitados. Comentários marcados como spam ou lixo podem se somar aos milhares num site aberto a comentários.
• Metadados órfãos. Registros de configuração associados a posts, usuários ou comentários que já não existem — sobras que perderam o dono.
• Tabelas de plugins removidos. Muitos plugins criam tabelas próprias e não as apagam quando são desinstalados. Elas ficam lá para sempre, ocupando espaço e confundindo.

Backup antes de qualquer coisa (a regra que não se negocia)#

Antes de tocar em uma linha do banco, faça um backup completo — do banco de dados e, de preferência, dos arquivos também. Mexer no banco é a operação de maior risco em um WordPress, porque um comando errado não tem "desfazer". Diferente de trocar um plugin, um DELETE mal calibrado apaga dados de verdade, na hora, sem lixeira. O backup é o que transforma uma limpeza arriscada numa limpeza tranquila: se algo der errado, você restaura e tenta de novo.

• Backup do banco especificamente. Um dump do banco (via painel, plugin ou linha de comando) é o que você restaura se uma limpeza apagar demais.
• Teste em staging, se puder. O ideal é rodar a limpeza primeiro num ambiente de testes idêntico, verificar que nada quebrou, e só então repetir na produção.
• Uma mudança de cada vez. Limpe uma categoria de lixo, confira o site, depois passe para a próxima. Assim, se algo quebrar, você sabe exatamente o quê foi.

Limpando as revisões de post#

As revisões são, quase sempre, o maior volume de lixo removível com segurança. Elas existem para você poder voltar a uma versão anterior de um texto — o que é útil —, mas guardar todas as versões de todos os posts para sempre é exagero. Um site com centenas de artigos muito editados pode ter milhares de revisões pesando no banco sem oferecer valor real.

Há duas frentes aqui: limpar as revisões que já existem e limitar quantas o WordPress guarda daqui para frente. A limpeza pontual remove o acúmulo histórico; o limite evita que ele volte.

• Apague o histórico acumulado. Plugins de otimização de banco removem revisões antigas em lote com segurança. Você escolhe manter as mais recentes de cada post e descartar o resto.
• Limite as revisões futuras. É possível dizer ao WordPress para guardar apenas as últimas versões de cada post (por exemplo, as três ou cinco mais recentes), em vez de infinitas. Isso mantém a capacidade de desfazer sem deixar o banco crescer sem freio.
• Não confunda revisão com backup. Revisões são para voltar uma edição, não para recuperar o site. Apagá-las não afeta seus backups nem o conteúdo publicado.

Varrendo transients, spam e lixeira#

Depois das revisões, vêm os acúmulos do dia a dia. Transients expirados são dados que já perderam a validade e não servem para nada — limpá-los é seguro e o WordPress simplesmente os recria quando precisar. Comentários de spam e itens na lixeira são lixo por definição: você já decidiu que não os quer.

• Transients expirados. Podem ser removidos sem dó; são cache temporário. Se um plugin precisar de algum, ele o gera de novo na hora.
• Spam e comentários na lixeira. Esvazie o spam e a lixeira de comentários. Num site movimentado, isso sozinho pode remover milhares de linhas.
• Posts e páginas na lixeira. Rascunhos e conteúdos excluídos que você tem certeza de que não voltarão podem sair de vez.
• Pingbacks e trackbacks. Se você não usa esse recurso antigo de notificação entre blogs, costuma ser tudo spam — vale limpar e desligar.

Metadados órfãos e tabelas de plugins removidos#

Essa é a camada mais delicada, porque exige saber o que se está apagando. Metadados órfãos são registros que apontam para um post, usuário ou comentário que já não existe — sobras que ficaram para trás quando o "dono" foi apagado. São seguros de remover, mas a identificação precisa ser correta, e é aqui que uma boa ferramenta de otimização ajuda, porque ela sabe distinguir o órfão do registro legítimo.

As tabelas de plugins desinstalados são outro caso clássico. Muitos plugins criam tabelas próprias e não fazem faxina ao serem removidos, deixando estruturas inteiras ocupando espaço. Removê-las é seguro desde que você tenha certeza absoluta de que o plugin dono já não existe e não voltará. Na dúvida, não apague — o ganho de apagar uma tabela é pequeno, e o risco de remover a tabela errada é grande.

• Órfãos: seguros, mas identifique certo. Use ferramenta que reconheça o órfão de verdade; não saia apagando metadados no chute.
• Tabelas antigas: só com certeza. Confirme que o plugin dono foi desinstalado de fato. Anote o nome da tabela e confira antes.
• Na dúvida, deixe. O espaço que essas sobras ocupam raramente é o gargalo. A prudência vale mais que os poucos megabytes economizados.

O que "otimizar tabela" realmente faz#

Depois de apagar muita coisa, o banco fica com "buracos" — espaço que foi liberado mas continua reservado, como uma estante com lacunas depois que você tira livros. Otimizar a tabela é o processo que reorganiza esse espaço, compacta o que sobrou e reconstrói os índices, deixando as leituras mais eficientes. É o passo que dá sentido à limpeza: apagar o lixo libera o espaço, otimizar reorganiza o que ficou.

• Compacta o espaço liberado. Devolve ao banco o espaço que os DELETE desocuparam, evitando fragmentação.
• Reconstrói índices. Índices bem organizados são o que torna as buscas do banco rápidas; otimizar os põe em ordem.
• Faça depois da limpeza. Otimizar antes de limpar reorganiza o lixo; o certo é limpar primeiro, otimizar depois.

O que você nunca deve tocar#

Tão importante quanto saber o que limpar é saber o que deixar em paz. O banco do WordPress tem tabelas centrais que sustentam o site inteiro, e mexer nelas manualmente é o caminho mais curto para um site quebrado. A regra geral: se você não tem certeza absoluta do que uma tabela ou linha faz, não a apague.

• Tabelas do núcleo. As tabelas de posts, usuários, opções e seus metadados são o coração do site. Limpe conteúdo dentro delas (revisões, órfãos) com ferramentas confiáveis, mas nunca apague as tabelas em si.
• A tabela de opções ativa. Ela guarda as configurações do site. Há entradas "autoload" que carregam em toda página — um plugin pode deixar lixo pesado ali —, mas editar isso exige saber exatamente o que se remove.
• Prefixos de tabela e estrutura. Não renomeie tabelas nem mexa em prefixos sem entender a fundo as consequências; o WordPress procura nomes específicos.
• Dados de plugins ativos. Só considere apagar tabelas de plugins que você tem certeza de terem sido desinstalados. Tabela de plugin ativo é dado em uso.

Uma rotina de manutenção que se sustenta#

Limpeza de banco não é evento único; é higiene periódica. Fazer uma faxina gigante uma vez e nunca mais é menos eficaz do que uma rotina leve e regular, porque o lixo volta a acumular naturalmente com o uso normal do site. O objetivo é manter o banco enxuto de forma contínua, não fazer cirurgias de emergência.

• Limite as revisões desde já. Configurar o teto de revisões é a prevenção mais eficaz — corta a maior fonte de inchaço na origem.
• Agende limpezas leves. Muitos plugins de otimização agendam a remoção automática de transients expirados, spam e lixeira. Configure e esqueça.
• Reavalie ao desinstalar plugins. Ao remover um plugin, verifique se ele deixou tabelas para trás e, com certeza da autoria, faça a faxina.
• Monitore o tamanho. Acompanhar o tamanho do banco ao longo do tempo mostra se algo está crescendo fora do normal — sinal de um plugin gerando lixo em excesso.

Cuidar do banco de dados é a otimização que quase ninguém faz e que quase sempre surpreende pelo ganho. Um banco enxuto responde mais rápido a cada consulta, deixa o painel leve, acelera as buscas e ajuda o site inteiro a respirar. O segredo é fazer isso com respeito ao risco: backup antes, uma mudança por vez, ferramentas confiáveis para o que é delicado, e mãos longe das tabelas do núcleo. Feito com método, é meia hora de trabalho que devolve velocidade que nenhuma troca de plugin de cache traria.