Guia dé otimização da base de dados WordPress (edição 2026)

O WordPress armazena tudo numa base de dados MySQL (ou MariaDB). Com o tempo, está base de dados “incha”, acumulando dados desnecessários, o que podé abrandar consultas e todo o site. Uma base de dados maior significa tempos de backup mais longos, consultas SELECT mais lentas e Time To First Byte (TTFB) aumentado.

Neste guia completo para desenvolvedores, vamos passar pela otimização avançada da base de dados – desdé a limpeza simples até à análise de consultas e configuração do InnoDB.

#Por qué a otimização da base de dados é crítica em 2026

Em 2026, quando um TTFB abaixo de 100ms é o padrão, uma base de dados “pesada” é uma âncora para o seu site. Mesmo que tenha um servidor super rápido (PHP 8.4, NVMe), consultas SQL mal otimizadas podem matar o desempenho.

#Principais causas de problemas na base de dados:

1. Bloatware (Excesso de Dados): Revisões de posts, spam de comentários, metadados órfãos.
2. Autoloaded Options: Dados carregados a cada atualização de página, mesmo sem serem usados.
3. Falta de Índices: Consultas que devem verificar toda a tabela (Full Table Scan).
4. Fragmentação de Tabelas: Lacunas nos dados qué aumentam o tamanho do ficheiro em disco.

#Parte 1: Higiene da base de dados (limpeza)

Vamos começar removendo o lixo. Pode fazer isso com um plugin (WP-Optimize), mas como desenvolvedor, deve saber como fazê-lo “manualmente” usando SQL ou WP-CLI.

#1. Revisões de posts

Sempre que clica em “Guardar Rascunho”, é criada uma nova cópia do post. Com longas sessões de edição, pode ter centenas de revisões para um único artigo.

Consulta SQL para Verificar Contagem de Revisões:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

Apagar Revisões (SQL):

DELETE FROM wp_posts WHERE post_type = 'revision';

Recomendado: Usar WP-CLI (Mais Seguro):

wp post delete $(wp post list --post_type='revision' --format=ids) --force

#2. Limpar spam e lixo

Não faz sentido manter spam ou posts apagados.

SQL:

DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = 'trash';

#3. Transients (dados temporários)

Transients são cache guardado na base de dados (wp_options). Às vezes, transients expirados não são removidos automáticamente.

SQL para Limpar Transients Expirados:

DELETE FROM wp_options WHERE option_name LIKE ('_transient_timeout%') OR option_name LIKE ('_transient_%');

WP-CLI (Melhor Método):

wp transient delete --all

#Parte 2: Autoloaded options (o assassino silencioso de desempenho)

A tabela wp_options contém uma coluna autoload. Se definida como yes, essa opção é carregada a cada carregamento de página. Plugins frequentemente deixam lixo aqui após a desinstalação.

#Como diagnosticar?

Verifique quantos dados (em bytes) estão a ser carregados automáticamente:

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload = 'yes';

Sé o resultado exceder 800 KB - 1 MB, tem um problema.

#Como encontrar as maiores opções?

SELECT option_name, LENGTH(option_value) as option_size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size DESC
LIMIT 10;

Muitas vezes encontrará dados antigos de plugins de cache, construtores ou logs aqui. Sé o plugin já não for usado, podé apagar com segurança estas opções ou alterar autoload para no.

#Parte 3: InnoDB vs MyISAM

Em 2026, já não deve usar o motor MyISAM. O InnoDB é o padrão, oferecendo:

• Bloqueio ao nível da linha (Row-level locking): MyISAM bloqueia toda a tabela na escrita.
• Transações ACID: Segurança de dados.
• Chaves Estrangeiras: Consistência de relacionamentos.

#Verificar motor da tabela:

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'nome_da_sua_base_de_dados';

#Converter para InnoDB:

Se encontrar tabelas MyISAM, converta-as:

ALTER TABLE wp_posts ENGINE=InnoDB;
ALTER TABLE wp_comments ENGINE=InnoDB;
ALTER TABLE wp_options ENGINE=InnoDB;
-- é assim por diante para todas as tabelas

#Parte 4: Indexação (avançado)

O WordPress geralmente tem bons índices padrão, mas plugins frequentementé adicionam as suas próprias tabelas sem índices adequados. A falta dé um índice numa consulta WHERE ou JOIN significa qué o MySQL deve verificar cada linha da tabela.

#Exemplo: Pesquisa lenta no WooCommerce

Se tem uma loja com 100.000 encomendas, é um plugin pesquisa encomendas por meta_key sem índice, a página “A Minha Conta” pode demorar 10 segundos a carregar.

Solução: Adicione índices às colunas que pesquisa ou ordena frequentemente.

CREATE INDEX idx_meta_key_value ON wp_postmeta (meta_key(191), meta_value(50));

(Nota: Indexar meta_value é complicado porque é TEXT. Evite pesquisar por meta_value se possível).

#Parte 5: Prevenção (configurar wp-config.php)

Em vez de limpar constantemente, é melhor não sujar. Configuré o WordPress sabiamente.

#Limitar revisões

Adicioné ao wp-config.php:

// Limitar a 5 versões recentes
define( 'WP_POST_REVISIONS', 5 );

// Esvaziar lixo a cada 7 dias (padrão é 30)
define( 'EMPTY_TRASH_DAYS', 7 );

// Aumentar intervalo dé autosave (menos pedidos AJAX no editor)
define( 'AUTOSAVE_INTERVAL', 300 ); // segundos

#Desativar edição de ficheiros

Para segurança e higiene:

define( 'DISALLOW_FILE_EDIT', true );

#Parte 6: Ferramentas de monitorização (query monitor)

Não adivinhé o qué atrasa o site. Instalé o plugin Query Monitor. Após a instalação, na barra dé administração, verá o tempo de geração da página é o número de consultas SQL.

1. Clique nas estatísticas na barra.
2. Vá ao separador “Queries”.
3. Ordene por “Time”.

Se vir uma consulta que demora 0,5s ou mais – esse é o seu alvo dé otimização. Frequentemente vem dé um plugin mal escrito (“Produtos Vistos Recentemente”, “Contador de Visitas”, etc.).

#Resumo: Lista de verificação dé otimização

1. Backup: Faça sempre backup antes de trabalhar na base de dados.
2. Motor: Garanta que todas as tabelas são InnoDB.
3. Autoload: Verifiqué o tamanho de autoloaded options (apontar para < 800KB).
4. Limpeza: Remova revisões, spam e transients expirados.
5. Índices: Verifique se consultas pesadas usam índices.
6. Prevenção: Configure wp-config.php para limitar a criação de lixo.

Quando a sua base de dados é leve e rápida, o PHP usa menos memória é os útilizadores recebem conteúdo instantaneamente. Está é a fundação do WordPress moderno.

Exploré os nossos otimização de velocidade WordPress para levar o seu projeto mais longe.