Otimizar o banco de dados do WordPress com segurança significa medir antes de apagar. O ganho real vem de localizar tabelas grandes, revisões excessivas, opções carregadas automaticamente, transientes vencidos e resíduos de plugins, sempre com backup restaurável. Comandos genéricos de “limpeza total” podem remover dados ainda usados e raramente corrigem uma consulta lenta sem identificar sua origem.
Conteúdo revisado em 21/09/2026. Execute limpeza primeiro em staging e mantenha uma cópia do banco fora do servidor.
Quando o banco do WordPress precisa de atenção
O banco guarda posts, páginas, configurações, usuários, comentários e dados de plugins. Ele cresce naturalmente. Tamanho, sozinho, não é defeito: uma loja com pedidos pode ter gigabytes legítimos. O problema surge quando tabelas aumentam sem relação com o negócio, o painel demora, consultas ocupam CPU, backups ficam longos ou a tabela de opções carrega muitos dados em toda requisição.
Antes de limpar, confirme se a lentidão está no banco. Imagens pesadas, chamada externa, PHP antigo, falta de cache ou servidor saturado produzem sintomas parecidos.
Faça backup e teste a restauração
Exporte o banco com a ferramenta da hospedagem, phpMyAdmin, WP-CLI ou mysqldump. Guarde a cópia fora da conta. Para sites com muitas gravações, programe uma janela ou use um método consistente oferecido pelo provedor. Um arquivo SQL incompleto pode aparentar sucesso e falhar somente no momento da recuperação.
O manual de backups do WordPress diferencia os arquivos do banco: ambos são necessários para restaurar o site por completo. Faça uma restauração em staging e confirme login, páginas e dados críticos.
Crie uma linha de base
Registre tamanho total, maiores tabelas, número de opções, tempo de backup e páginas lentas. No WP-CLI:
wp db size --tables
wp db tables
wp option list --autoload=on --format=total_bytesO último comando depende da versão do WP-CLI e do WordPress. Se não estiver disponível, consulte o banco com cuidado. O prefixo pode ser diferente de wp_:
SELECT table_name,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS tamanho_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length + index_length DESC;Não execute consultas de remoção copiadas da internet antes de entender o esquema. Plugins criam tabelas próprias e relacionamentos que não aparecem no núcleo.
O que costuma ocupar espaço
| Origem | Benefício da limpeza | Risco |
|---|---|---|
| Revisões antigas | Reduz linhas em posts e metadados | Perde histórico de edição |
| Transientes vencidos | Remove cache que deveria expirar | Pico temporário ao recalcular |
| Spam e lixeira | Diminui comentários e metadados | Excluir item classificado errado |
| Logs e filas | Pode liberar muito espaço | Apagar auditoria ou tarefa pendente |
| Tabelas órfãs | Remove resíduos de plugins | Plugin ainda pode depender delas |
| Autoload excessivo | Reduz dados em toda requisição | Quebrar configuração essencial |
Como tratar revisões de posts
Revisões ajudam a recuperar alterações e comparar edições. Em um site com páginas modificadas muitas vezes, elas podem crescer. Defina uma política antes de apagar: preservar as últimas revisões por conteúdo é mais útil que remover tudo.
Para limitar futuras revisões, adicione ao wp-config.php:
define( 'WP_POST_REVISIONS', 10 );O limite não apaga revisões existentes imediatamente. Faça a limpeza com uma ferramenta que preserve as versões desejadas e teste páginas com construtores, pois alguns armazenam dados extensos em cada revisão.
Transientes vencidos e cache
Transientes são valores temporários. Plugins devem respeitar a expiração, mas resíduos podem permanecer. Com WP-CLI:
wp transient delete --expired
wp site transient delete --expiredEm multisite, confirme o escopo. Remover transientes válidos não costuma apagar conteúdo, mas força reconstrução de cache e pode aumentar carga. Faça fora do pico e acompanhe o site.
Por que autoload merece atenção
Opções marcadas para carregamento automático entram na memória em muitas requisições. Uma opção grande de plugin, cache persistido ou configuração abandonada pode prejudicar o tempo de resposta mesmo quando a tabela total é pequena.
Liste as maiores opções carregadas automaticamente, adaptando o prefixo:
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 30;Os valores de autoload aceitos mudaram ao longo das versões do WordPress, por isso a consulta inclui formas diferentes. Não altere para “não” sem consultar o plugin ou testar: algumas opções precisam estar disponíveis cedo. Se o componente foi removido, procure o procedimento oficial de desinstalação antes de excluir manualmente.
Comentários, spam e lixeira
Revise a fila no painel e elimine spam confirmado e itens na lixeira. A exclusão também deve remover metadados relacionados por meio das APIs do WordPress. Evite um DELETE direto que deixa registros órfãos. Em sites atacados por spam, corrija a entrada com antispam, limitação e atualização; caso contrário, a tabela crescerá novamente.
Logs, sessões e filas de plugins
Plugins de segurança, estatística, formulário e comércio podem manter logs, sessões e filas. Verifique a política de retenção dentro do próprio plugin. Uma tabela de fila enorme pode conter tarefas pendentes, não lixo. Primeiro identifique estados, datas e recorrência; depois use a ferramenta de limpeza do componente.
Se uma tabela volta a crescer, descubra o produtor. Erro repetido, webhook falhando ou tarefa cron parada cria milhões de linhas novamente após uma limpeza bem-sucedida.
Como identificar tabelas órfãs
Compare prefixos e nomes com os plugins ativos, mu-plugins e histórico do site. Pesquise a documentação do fornecedor e confira se o plugin oferece opção para remover dados ao desinstalar. Faça backup isolado das tabelas candidatas, renomeie-as em staging e percorra as funções do site antes de excluí-las.
Não considere órfã uma tabela apenas porque o nome do plugin não é óbvio. Bibliotecas compartilhadas e integrações antigas podem usar nomes próprios.
Reparar e otimizar tabelas
O WordPress oferece uma tela de reparo quando você define temporariamente:
define( 'WP_ALLOW_REPAIR', true );Acesse /wp-admin/maint/repair.php e remova a constante ao concluir. A documentação do wp-config.php alerta que a página não exige login enquanto a opção está ativa. Use-a apenas durante a manutenção.
Com WP-CLI, há também:
wp db check
wp db optimizeO comando de otimização executa operações do banco e pode bloquear tabelas ou exigir espaço temporário. Leia a referência do WP-CLI, programe janela e evite rodar como tarefa diária sem motivo.
Índices e consultas lentas
Quando a página continua lenta, use log de consultas lentas, APM ou uma ferramenta de diagnóstico para localizar a consulta. Tabelas de metadados são flexíveis, mas buscas por combinações complexas podem custar caro. Um índice adicional pode ajudar uma consulta específica e prejudicar gravações ou futuras atualizações.
Antes de criar índice, registre a consulta, execute EXPLAIN em staging, compare linhas examinadas e tempo e documente a alteração. Para plugins conhecidos, prefira índices recomendados pelo fornecedor.
Rotina mensal de manutenção
- Confirme backups automáticos e restauração recente.
- Registre tamanho das tabelas e crescimento desde o mês anterior.
- Revise spam, lixeira e retenção de logs.
- Elimine somente transientes vencidos.
- Inspecione opções autoload grandes.
- Verifique cron, filas e integrações com falha.
- Execute check do banco quando houver indício de corrupção.
- Compare desempenho antes e depois.
Perguntas frequentes
Plugin de limpeza deixa o site mais rápido?
Pode reduzir resíduos, mas desempenho depende da consulta e dos dados carregados. Meça antes e depois; diminuir megabytes não garante menor tempo de resposta.
Posso apagar todas as revisões?
Pode, mas perde o histórico. Normalmente é melhor preservar uma quantidade útil e limitar o crescimento futuro.
OPTIMIZE TABLE precisa ser executado sempre?
Não. O benefício depende da engine e das alterações. Pode consumir espaço e bloquear operações; use quando houver evidência e janela adequada.
Banco grande prejudica SEO?
Não diretamente. Consultas lentas podem aumentar o tempo de resposta, afetar experiência e rastreamento. O foco deve ser desempenho mensurável e estabilidade.
Conclusão
Uma otimização segura começa por inventário e backup. Limpe dados com significado conhecido, ajuste retenção e corrija o processo que causa crescimento. Preserve revisões úteis, trate autoload com cuidado e use as APIs do WordPress ou a ferramenta do plugin.
Depois compare tamanho, tempo de consulta, uso de recursos e jornada do usuário. Esse registro mostra se a manutenção trouxe resultado e cria uma linha de base para detectar anomalias antes que o banco volte a ser um problema.
