Uma base de dados com vários gigabytes não explica, por si só, porque um WordPress demora a responder. Também uma base relativamente pequena pode prejudicar o desempenho se determinadas consultas forem ineficientes ou executadas vezes de mais.
Antes de «limpar a base de dados», importa perceber que operação está lenta, quanto tempo é gasto nas consultas e se a causa está realmente na base de dados. O problema pode estar no código de um plugin, no processamento PHP ou nos recursos do servidor.
O que o WordPress guarda na base de dados
O WordPress guarda na base de dados artigos, páginas, utilizadores, comentários, taxonomias e configurações. Os ficheiros das imagens, por exemplo, ficam normalmente no armazenamento do servidor, enquanto os seus dados associados são registados na base de dados.
Entre as tabelas habituais estão wp_posts, wp_postmeta, wp_options, wp_users e wp_usermeta. O prefixo wp_ é apenas um exemplo: pode ser diferente em cada instalação. Os plugins podem criar tabelas próprias para registos de atividade, estatísticas, tarefas ou outras funcionalidades. No WooCommerce, juntam-se produtos, variações, sessões e dados de encomendas, entre outros.
O tamanho total não mede a eficiência das consultas. Imagine dois casos hipotéticos: uma instalação com 3 GB, cujas consultas usam índices adequados e recuperam poucos registos; outra com 300 MB, mas com filtros de produtos que examinam demasiados dados. A segunda pode responder muito mais lentamente, apesar de ocupar menos espaço.
Onde aparece a lentidão?
A primeira pista é identificar a operação afetada. Uma pesquisa lenta, uma página do painel de administração demorada e uma importação que não termina podem ter causas distintas.
| Sintoma observado | Primeira área a investigar |
|---|---|
| Pesquisa ou filtros de produtos lentos | Consultas a metadados e taxonomias, critérios de ordenação e índices. |
| Painel de administração lento, mas páginas públicas rápidas | Consultas e processamento específicos do painel, plugins e chamadas a serviços externos. |
| Finalização da compra ou gestão de encomendas lenta | Consultas e atualizações de encomendas, extensões e integrações; verificar também a configuração HPOS. |
| Importações ou tarefas agendadas demoradas | Operações em lote, filas de tarefas, concorrência e recursos disponíveis. |
| Lentidão geral, sobretudo com mais tráfego | CPU, memória, acesso ao disco, processos PHP e atividade da base de dados. |
Estes sinais orientam a investigação; não demonstram a causa. Uma página pública servida por cache pode parecer rápida mesmo quando os pedidos que executam WordPress estão lentos. Convém medir a operação concreta, sem confundir tempos de carregamento no navegador com tempo gasto em consultas SQL.
Consultas lentas e consultas repetidas
Uma consulta à base de dados, ou query SQL, pode recuperar um artigo, selecionar produtos ou obter configurações. Algumas exigem combinações entre tabelas, filtros e ordenações. Tornam-se problemáticas quando examinam demasiados registos, demoram a executar ou se repetem sem necessidade.
A repetição é fácil de subestimar. Num exemplo hipotético, uma consulta de 10 milissegundos, executada 300 vezes durante o mesmo pedido, representa 3 segundos de tempo acumulado em consultas. Nenhuma execução individual parece especialmente lenta, mas o conjunto pode ter um impacto significativo. É um comportamento possível em ciclos de código de plugins, modelos de página ou integrações.
O diagnóstico deve considerar, por isso, três aspetos em conjunto: duração de cada consulta, frequência e origem. Reduzir consultas repetidas pode ser mais útil do que eliminar milhares de registos que não participam nessa operação.
Áreas que merecem atenção no WordPress
wp_options e carregamento automático (autoload)
A tabela wp_options contém configurações do WordPress, de temas e de plugins. Algumas são carregadas automaticamente durante os pedidos, através do mecanismo autoload. Isso é adequado para informação usada com frequência, mas torna-se dispendioso quando inclui grandes volumes de dados desnecessários.
A ferramenta de Diagnóstico do site do WordPress, disponível na área de Ferramentas, pode sinalizar um volume excessivo de opções carregadas automaticamente. O aviso é um motivo para investigar, não para apagar entradas por tamanho. Antes de remover uma opção ou alterar o seu carregamento automático, é necessário identificar a origem, confirmar se continua a ser usada e avaliar as consequências.
Metadados, pesquisas e índices
As tabelas de metadados, como wp_postmeta, permitem associar referências, marcas ou campos personalizados a artigos e produtos. Essa flexibilidade é útil, mas pesquisas com vários critérios e ordenações podem tornar-se exigentes, sobretudo em catálogos extensos.
Os índices ajudam a localizar registos sem percorrer toda a tabela. Um índice adequado pode acelerar determinada consulta, mas acrescenta espaço ocupado e trabalho nas operações de escrita. A decisão deve partir das consultas identificadas, não de uma lista genérica de índices a instalar. Em projetos com muitos dados estruturados, também pode justificar-se rever o modelo de armazenamento.
Dados temporários, revisões e tabelas dos plugins
Os transients guardam dados temporários, como resultados de pedidos a serviços externos. Sem cache persistente de objetos, podem ser guardados na base de dados; com essa cache, podem ficar num sistema externo. Apagar indiscriminadamente estes dados pode obrigar o WordPress e os plugins a recriá-los, sem resolver a origem do problema.
As revisões de artigos, os registos antigos e o histórico de determinadas extensões também ocupam espaço. Uma política de retenção adequada pode melhorar a gestão da base de dados e das cópias de segurança. Porém, reduzir o tamanho dessas tabelas não garante uma melhoria no tempo de resposta das páginas. É necessário perceber se participam nas consultas lentas e se os dados podem ser removidos em segurança.
WooCommerce, HPOS e Action Scheduler
Numa loja online existem consultas e atualizações frequentes relacionadas com produtos, stock, clientes e encomendas. O High-Performance Order Storage (HPOS) utiliza tabelas dedicadas para dados de encomendas, quando está ativo. Pode melhorar a escalabilidade dessa área, mas não corrige, por si só, filtros de produtos, opções carregadas automaticamente ou consultas ineficientes de plugins. Em lojas existentes, é necessário confirmar a ativação e a compatibilidade das extensões.
O Action Scheduler, utilizado pelo WooCommerce e por vários plugins, gere tarefas agendadas e mantém informação sobre a sua execução. Filas acumuladas ou ações repetidamente falhadas justificam investigar que extensão as cria e porque não estão a ser processadas corretamente. Apagar o histórico sem corrigir a causa pode fazer com que o problema regresse.
Como confirmar se são as consultas à base de dados
O Query Monitor permite observar, num pedido WordPress, o número de consultas, os respetivos tempos e, em muitos casos, os componentes responsáveis. É útil para investigar uma operação reproduzível, mas não avalia automaticamente todos os processos do servidor nem prova que uma consulta listada seja a causa da lentidão.
Para problemas intermitentes ou que surgem sob carga, os registos de consultas lentas (slow query log) do MySQL ou MariaDB podem ajudar a identificar operações demoradas. É necessário configurar adequadamente a recolha e analisar os registos com critério, evitando deixá-la ativa sem controlo.
Depois de encontrar uma consulta suspeita, o comando EXPLAIN permite estudar o seu plano de execução: tabelas percorridas, índices considerados e forma de combinação dos dados. Esta análise técnica ajuda a decidir se o problema exige alterar a consulta, os índices ou a estrutura dos dados.
Os resultados devem ser confrontados com a utilização de CPU, memória, disco e processos PHP, bem como com eventuais esperas e operações concorrentes. Uma consulta pode tornar-se lenta durante um pico de carga sem que o seu desenho seja a única causa.
Limpeza, otimização e cache: intervenções diferentes
Limpar a base de dados significa remover informação comprovadamente dispensável, como determinados registos antigos ou dados temporários expirados. Pode facilitar a manutenção e reduzir o espaço ocupado, mas não corrige necessariamente o processamento que está a atrasar uma página.
Otimizar as consultas significa reduzir trabalho desnecessário: rever código, evitar repetições, utilizar índices adequados ou melhorar a organização dos dados. Executar periodicamente OPTIMIZE TABLE não substitui este trabalho. Trata-se de uma operação de manutenção que pode fazer sentido em circunstâncias específicas, por exemplo após grandes eliminações, e deve ser avaliada pelo seu custo e risco.
A cache persistente de objetos, através de soluções como Redis ou Memcached, pode reutilizar determinados dados entre pedidos e reduzir o número de consultas à base de dados. Não deve ser confundida com a cache de página ou com o OPcache do PHP. Também não elimina a necessidade de corrigir uma consulta ineficiente quando esta continua a ser executada.
Quando a limitação comprovada está na capacidade do servidor, pode ser necessário ajustar recursos ou configuração. Aumentar memória ou CPU sem identificar o ponto de estrangulamento é tão pouco rigoroso como apagar tabelas sem diagnóstico.
Como fazer um diagnóstico seguro
- Delimitar o problema. Identificar a página ou operação lenta, quando acontece e se afeta visitantes, utilizadores autenticados ou tarefas internas.
- Medir antes de alterar. Registar tempos de resposta e, quando possível, tempo de consultas e utilização de recursos, em condições representativas.
- Localizar o trabalho mais dispendioso. Procurar consultas lentas ou repetidas, relacionando-as com plugins, temas, integrações e processos agendados.
- Verificar os dados envolvidos. Analisar opções carregadas automaticamente, metadados, tabelas em crescimento, filas de tarefas e eventuais limitações do servidor.
- Aplicar uma alteração justificada. Corrigir a consulta ou o processo, ajustar uma opção, rever um índice, ativar uma cache adequada ou eliminar dados dispensáveis, conforme a evidência encontrada.
- Medir novamente. Comparar os resultados em condições semelhantes e confirmar que a melhoria não provocou erros noutras funcionalidades.
Antes de eliminar dados, alterar índices ou executar operações de manutenção, deve existir uma cópia de segurança verificada e um plano de recuperação e, nas alterações relevantes, um teste em ambiente separado. Em lojas ativas, qualquer plano de restauro exige cuidado adicional para não substituir encomendas e outras alterações entretanto registadas.
Conclusão
Uma base de dados WordPress grande não é necessariamente lenta, e uma limpeza automática não é um diagnóstico. O critério é identificar que consultas ou processos estão a atrasar uma operação, porque o fazem e que intervenção melhora efetivamente o resultado. Só essa relação entre medição, causa e validação permite otimizar com segurança.
