Performance

Otimizar a base de dados WordPress: limpar o lixo que pesa no site

Quase ninguém culpa a base de dados quando o WordPress arrasta. Culpa-se o alojamento, o tema, o plugin de cache. Mas, ao fim de dois ou três anos, a wp_options cresce para 50 MB, o wp_postmeta está cheio de meta órfãs de plugins desinstalados, e cada carregamento de página puxa milhares de linhas para memória. O site não está lento por causa da web — está lento por causa da casa que carrega às costas.

Este guia mostra o que vale a pena limpar, o que não vale, com que ferramentas, e com que frequência. Sem promessas de "10× mais rápido": expectativa real é TTFB que cai 100-300 ms e backoffice que volta a responder.

1. O problema real não é o tamanho — é o autoload

A wp_options tem uma coluna autoload. Tudo o que está marcado como yes é carregado em todos os pedidos, mesmo no frontend público. Plugins mal-comportados deixam lá megabytes de dados que ninguém precisa.

Verifica o tamanho do autoload com uma query simples (via phpMyAdmin ou Adminer):

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_mb
FROM wp_options WHERE autoload = 'yes';

Valores de referência:

  • < 1 MB: saudável.
  • 1-3 MB: cinzento, tolerável.
  • > 3 MB: está a estrangular o site. Auditar.

Para ver os culpados:

SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options WHERE autoload = 'yes'
ORDER BY bytes DESC LIMIT 20;

Vais reconhecer lixo de plugins antigos (caches de afiliados, logs de imports, settings de SEO já trocado). Esses entries são candidatos a mudar autoload para no ou apagar.

2. Revisões de posts — limitar, não eliminar

Cada vez que guardas um post no editor, o WordPress cria uma revisão. Por defeito, são ilimitadas. Um post antigo pode ter 80 revisões. Multiplica por mil posts e tens dezenas de milhares de linhas em wp_posts.

Limita no wp-config.php:

define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );

Mantém 5 revisões por post (suficiente para recuperar um erro recente) e poupa o autosave a cada 2 minutos em vez de 60 segundos. As revisões antigas continuam lá — para apagar, ver §5.

3. Transients — caches que ninguém vai limpar por ti

Os transients são caches temporários (ex.: resultado de uma chamada à API do Instagram que vale 1 hora). Idealmente expiram sozinhos. Na prática, transients com expiração mal definida ficam para sempre na wp_options.

Para detetar:

SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_%';

Mais de algumas centenas é sinal de plugin a deixar lixo. Limpar transients expirados é seguro — eles são, por definição, descartáveis.

4. Spam, lixeira e meta órfãs

Três fontes silenciosas de bloat:

  • Comentários spam e lixeira: o Akismet apanha, mas só marca. Ficam em wp_comments. Apagar definitivamente a cada 30 dias.
  • Posts/páginas na lixeira: o WordPress esvazia automaticamente ao fim de 30 dias (configurável com EMPTY_TRASH_DAYS). Se desativaste isso, está lá tudo.
  • Postmeta órfã: linhas em wp_postmeta cujo post_id já não existe. Aparece quando apagas posts diretamente da base de dados sem cascata, ou quando plugins de portfólio/CPT são desinstalados.

Query para detetar postmeta órfã (não executes o DELETE sem backup):

SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;

5. Ferramentas: o que usar, o que evitar

Não precisas de cinco plugins. Um chega.

  • WP-Optimize (gratuito): o mais completo para limpeza. Faz revisões, transients, comentários spam, tabelas órfãs, otimização de tabelas (OPTIMIZE TABLE). Tem agendamento.
  • Advanced Database Cleaner: especialista em órfãs de plugins desinstalados e tabelas que ficaram a mais.
  • WP-CLI (se tens SSH): wp transient delete --expired, wp post delete $(wp post list --post_status=trash --format=ids). Mais cirúrgico, sem plugin.

Evita plugins que prometem "otimização total da base de dados" + cache + minificação tudo junto. Misturam responsabilidades e quebram o site na hora errada.

6. OPTIMIZE TABLE — vale a pena?

OPTIMIZE TABLE reorganiza fisicamente a tabela e liberta espaço fragmentado. Em InnoDB (o motor por defeito desde há anos), o ganho é marginal e a tabela fica bloqueada durante a operação. Em sites grandes (>500 MB de base de dados) corre o risco de timeout do PHP a meio.

Regra prática:

  • Site pequeno (< 100 MB): correr de 3 em 3 meses, à noite, com backup feito.
  • Site médio/grande: só depois de limpar bulk grande (ex.: apagaste 100k linhas de revisões). Caso contrário, ignora.

7. Frequência — não é semanal

Limpar a base de dados todos os dias é teatro de produtividade. O bloat constrói-se devagar. Cadência sensata:

TarefaFrequência
Spam + lixeira de comentáriosMensal (ou automático)
Transients expiradosMensal
Revisões acima do limiteTrimestral
Postmeta órfã + tabelas de plugins desinstaladosSemestral
Auditoria do autoloadQuando o backoffice começa a arrastar

Agenda no WP-Optimize ou via WP-CLI cron. Não dependas da memória.

8. Backup obrigatório antes de qualquer DELETE

Não há exceção. Antes de correr qualquer otimização que apague linhas:

  1. Backup completo da base de dados (mysqldump ou plugin de backup).
  2. Backup dos ficheiros (wp-content/).
  3. Guardar fora do servidor (Drive, S3, disco local).
  4. Testar restauro pelo menos uma vez em ambiente de staging.

Mais sobre estratégia de backup em cópias de segurança do site.

9. Quando otimizar a base de dados não chega

Se o site continua lento depois de limpar:

  • Alojamento partilhado saturado — disco lento, MySQL sem memória dedicada.
  • PHP desatualizado (< 8.1) — perdes 30-40% de performance só por isso.
  • Plugins pesados — page builders pesados, plugins de tradução, multistore. Auditar com Query Monitor.
  • Tema mal codificado — temas que fazem 200 queries por página.

Diagnosticar a causa real está em porque é que o teu site está lento e na lista de plugins WordPress essenciais para PME.

10. Riscos — o que não fazer

  • Não correr queries DELETE sem WHERE explícito. Apaga a base toda em segundos.
  • Não desativar o autoload do siteurl, home, blogname ou outras opções core — o WordPress quebra.
  • Não apagar tabelas com prefixo de plugin sem confirmar que o plugin está mesmo desinstalado e que não vais reativar.
  • Não confiar em "1-click optimize" sem backup. Já vimos sites que voltaram ao estado de instalação fresca.
  • Não usar plugins de "speed up" que prometem otimizar a base de dados + servir CDN + minificar JS — escolhe ferramentas com uma responsabilidade.

Em resumo

Uma base de dados WordPress saudável tem autoload < 1 MB, revisões limitadas, transients controlados, e é limpa trimestralmente. O ganho real é TTFB mais consistente e backoffice utilizável — não milagre de performance. Antes de qualquer limpeza: backup, backup e backup. E se o site continua lento depois disto, o problema está noutro lado.

No sitesfixe.pt construímos sites WordPress que carregam depressa desde o primeiro dia — base de dados magra, queries otimizadas, cache em camadas. Se o teu WordPress arrasta e o plugin de cache já não resolve, fala connosco. Sites desde 1.500€. Manutenção desde 80€/mês.

Lê também:

Fontes

Precisas de um site ou loja online?

Agência digital portuguesa. Sites e lojas online rápidos, otimizados para o Google e feitos para resultado.

Pedir orçamento