Quando um cliente relata telas administrativas lentas, falhas no checkout ou timeouts aleatórios, as agências não têm o luxo de analisar dezenas de tabelas ou fazer engenharia reversa do comportamento de plugins. É preciso reconhecer rapidamente os pontos prováveis de falha e concentrar a atenção onde realmente importa.
Na prática, a maioria dos problemas graves de desempenho e estabilidade pode ser rastreada até um pequeno número de tabelas do banco de dados que crescem sem controle ao longo do tempo. Essas tabelas não causam problemas em sites novos ou com pouco tráfego, mas após anos de conteúdo, plugins e atividade de usuários, elas passam a ser responsáveis por uma parcela desproporcional de falhas, consultas lentas e chamados emergenciais de suporte.
Este artigo se concentra em cinco tabelas do banco de dados do WordPress (e padrões de tabelas) que as agências de manutenção devem monitorar ativamente, pois são as mais propensas a causar problemas de desempenho no mundo real à medida que os sites crescem.
Por que as agências só precisam monitorar 20% do banco de dados
O princípio de Pareto ajuda a explicar muitos padrões operacionais e também se aplica à manutenção do banco de dados do WordPress. As agências não se deparam com problemas uniformemente em todo o banco de dados. Em vez disso, um pequeno subconjunto de tabelas é responsável pela maioria das lentidões, falhas e chamados urgentes de suporte relacionados ao banco de dados.
As instalações padrão do WordPress criam 12 tabelas. Algumas, como wp_users, wp_links e tabelas de taxonomia, podem operar por anos sem causar problemas. Normalmente, elas não acionam as consultas mais lentas que travam os sites durante picos de tráfego.
No entanto, as tabelas de maior risco compartilham uma característica: elas podem quebrar sites em escala. Um site com 100 artigos pode funcionar bem com revisões ilimitadas. Esse mesmo site, com 10.000 artigos e 300.000 entradas de revisão, provavelmente apresentará timeout em todas as telas de edição. Uma loja de eCommerce com 50 produtos deve ter um bom desempenho, mas ao escalar para 5.000 produtos, as páginas podem levar vários segundos para carregar.
Cinco padrões de banco de dados que fazem sites WordPress falharem em escala
Vamos analisar cinco padrões que aparecem com frequência no trabalho de manutenção de agências.
Eles não são imediatamente perigosos em sites pequenos, mas à medida que o conteúdo, o tráfego e a atividade de plugins aumentam, tornam-se as fontes mais comuns de consultas lentas, timeouts e problemas de estabilidade.
wp_options: inchaço do autoload pode travar sites de alto tráfego
A tabela wp_options armazena as configurações do site e dos plugins e determina quais opções o WordPress carrega em cada solicitação de página (inclusive páginas em cache). Entre as colunas, autoload é a mais importante:
O WordPress primeiro carrega todas as opções com autoload na memória em cada solicitação. Sites com um volume menor de autoload conseguem lidar com o tráfego normalmente, porém, conforme o autoload cresce, cada visitante passa a consumir mais memória do que o servidor aloca por processo PHP.
Se o tamanho do autoload ficar alto demais (por exemplo, acima de cerca de 3 MB), surgem telas administrativas lentas, falhas no checkout durante vendas e erros 502.
O culpado quase sempre é as configurações órfãs de plugins ou entradas temporárias de cache conhecidas como transients. Com o autoload habilitado, algumas opções de plugins que você removeu podem permanecer na tabela wp_options, o que significa que continuam sendo carregadas em todas as solicitações. Ao longo de meses ou anos, com dezenas de plugins, isso acumula dados abandonados que são carregados a cada visualização de página.
O console SQL do Database Studio mostrado acima permite executar uma consulta para verificar o tamanho dos dados carregados via autoload em bytes:
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Você também pode usar o console para executar outras consultas necessárias, como ordenar os resultados.
O plano aqui deve ser revisar os resultados, identificar a que se referem as grandes entradas de autoload e limpá-las, ou seja, excluir as linhas.
wp_postmeta: sites de eCommerce podem falhar por inchaço de metadados
A tabela wp_postmeta armazena campos personalizados de artigos, páginas e produtos. Toda vez que o conteúdo é salvo, novas entradas de metadados podem ser adicionadas. Plugins, em especial, costumam anexar dezenas de campos a um único artigo ou produto.
Por exemplo, o WooCommerce armazena dados de produtos em postmeta: variações, estoque, detalhes de envio e atributos. Um único produto com variações pode gerar dezenas de entradas de metadados. Catálogos grandes podem criar potencialmente milhões de linhas em postmeta.
O resultado de uma tabela wp_postmeta inflada são telas de edição com dificuldade para carregar dados, filtros de produtos extremamente lentos e pesquisas que entram em timeout ao tentar consultar tabelas enormes. Em geral, erros durante períodos de alto tráfego costumam ser causados por inchaço do wp_postmeta.
Usando o console SQL, você pode executar consultas para selecionar e excluir dados supérfluos semelhantes a wp_options. Você está procurando aspectos como tabelas postmeta de vários gigabytes, muitasmeta_keys duplicatas e metadados órfãos em geral. As opções de filtragem no Database Studio também são úteis aqui:
Por exemplo, você pode classificar por meta_key clicando na seta da coluna. Isso agrupa chaves idênticas, facilitando a identificação de padrões, como chaves de plugins removidos ou campos personalizados não utilizados.
wp_posts: revisões ilimitadas travam as telas de edição
A tabela wp_posts armazena o conteúdo e o histórico de revisões. Por padrão, o WordPress salva cada alteração como uma entrada separada no banco de dados, portanto, a edição regular de conteúdo gera uma quantidade significativa de dados extras. Sites com grande volume de conteúdo e históricos de edição podem acumular milhares de entradas de revisão.
Inicialmente, os sites funcionam bem, mas um grande número de revisões armazenadas pode fazer com que as telas administrativas fiquem lentas ao editar artigos. O WordPress salva automaticamente a cada 60 segundos durante a edição, e os autosaves também impactam negativamente, pois sessões longas de edição criam dezenas de entradas de salvamento automático.
Para remover as revisões rapidamente as revisões da tabela wp_posts (por exemplo):
Você pode então passar para o console SQL para executar uma consulta e excluir as revisões:
DELETE FROM wp_posts WHERE post_type="revision";
É uma boa prática comparar o número de revisões com o número de artigos publicados. Proporções de um dígito são razoáveis. Verifique também se as revisões representam mais da metade do total de entradas, pois isso indica provável inchaço. Revisões que crescem mês a mês sugerem a necessidade de implementar limites, o que pode ser feito com uma edição simples no arquivo wp-config.php.
Tabelas de plugins: formulários e logs crescem até seus sites quebrarem
Quase todo plugin cria tabelas personalizadas no banco de dados, mas isso é mais comum em plugins de formulários, busca e segurança. Essas tabelas podem continuar crescendo sem exigir manutenção integrada.
Em particular, plugins de formulários, geralmente armazenam, por padrão. Assim, se seus sites recebem tráfego constante de envios ao longo dos anos, você acumula milhares de registros de formulários. Além disso, tabelas relacionadas a logs crescem ainda mais rápido. Plugins de segurança registram ações de visitantes, plugins de análise acompanham visualizações de páginas e ferramentas de depuração registram erros.
Como acontece com muitos problemas de tabelas do banco de dados, as páginas entram em timeout, mas também começam a aparecer backups do banco de dados lentos e desempenho degradado que não se correlaciona com o tráfego. A ligação com o inchaço do banco de dados nem sempre é óbvia, porque os sintomas aparecem em áreas aparentemente não relacionadas.
Você deve procurar tabelas de plugins que se igualem ou superem o tamanho das tabelas principais do WordPress. Quanto maiores elas forem, mais importante se torna reduzi-las. Uma consulta SQL pode ajudar a identificá-las:
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
Se alguma dessas tabelas estiver órfã, você pode excluí-la com segurança. No entanto, embora isso esteja fora do escopo deste post, se alguma tabela for grande o suficiente para justificar redução, mas ainda for necessária para o site, será preciso pesquisar mais a fundo, possivelmente entrando em contato com o desenvolvedor para obter orientação.
Action Scheduler: tarefas com falha se acumulam e derrubam o checkout
O Action Scheduler gerencia e executa tarefas em segundo plano no WordPress. Ele enfileira tarefas, processa-as de forma assíncrona e armazena registros de conclusão permanentemente por padrão.
O uso do WooCommerce é uma boa forma de entender como o Action Scheduler pode causar problemas. Por exemplo, timeouts em gateways de pagamento resultam em ações com falha que permanecem no banco de dados e são consultadas a cada carregamento de página para verificar trabalho pendente. Basta extrapolar uma única ação com falha entre as milhares que uma loja WooCommerce típica gera por mês.
As Visualizações do Database Studio podem ajudar você a excluir essas ações com falha:
Aqui, defina um título para a visualização, selecione a tabela wp_actionscheduler_actions e clique no link Adicionar condição. Isso permite que você mostre apenas as ações com falha, tornando muito mais simples removê-las do banco de dados.
Como gerenciar as tabelas mais importantes do banco de dados do WordPress em 10 minutos por mês
Com o custo de apenas alguns minutos por mês, você pode reduzir bastante o trabalho de gerenciamento do banco de dados ao longo de um ano. É claro que não é necessário monitorar ou gerenciar muitas das tabelas do seu banco de dados:
- A tabela
wp_usersraramente causa problemas, a menos que você gerencie sites de membros com milhões de contas. Os dados de usuários geralmente crescem linearmente sem acumular nenhum inchaço. - As tabelas de taxonomia (como
wp_terms,wp_term_taxonomy,wp_term_relationships) geralmente permanecem estáveis, independentemente do tamanho do site.
Entre as cinco tabelas problemáticas, as grandes tabelas wp_posts em sites de conteúdo são típicas e esperadas. Lembre-se: conteúdo real não é inchaço.
Configurando seu fluxo de monitoramento
Exportar as tabelas do banco de dados permite trabalhar com os dados em outros aplicativos. Você pode fazer isso pelo menu suspenso de reticências More Items de qualquer tabela
No entanto, é possível fazer muita coisa no MyKinsta sem exportar. O melhor uso do seu tempo é automatizar limpezas e revisar manualmente as métricas do banco de dados. As views do Database Studio ajudam a configurar sua análise.
Por exemplo, você pode criar uma visualização personalizada que monitore wp_postmeta e adicionar filtros para padrões específicos de meta_key que você deseja rastrear:
O Database Studio permite criar e salvar snippets no console SQL, para que você configure uma consulta SQL que ordene todas as tabelas por tamanho e a acesse sempre que precisar:
Algumas das maiores tabelas devem ser wp_posts, wp_postmeta e wp_options. Você deve investigar todas as tabelas com classificação mais alta.
O monitoramento exato que você configura depende de seus sites e necessidades. No entanto, aqui estão algumas áreas que você deve examinar:
- Filtre
wp_optionspara ver se há carregamentos automáticos ativos e verifique o tamanho total (por meio de consultas SQL ou exportação para CSV). Qualquer coisa maior que 1 MB deve ser investigada. - Verifique o tamanho da tabela
wp_postmetaem relação ao mês anterior, especialmente se houver aumentos expressivos. - Você pode filtrar post_type em
wp_postspara comparar revisões com artigos. Se necessário, configure um limite no arquivowp-config.php. - No Action Scheduler, as ações concluídas devem superar em número as pendentes ou com falha.
Em resumo, use o Database Studio para criar as visualizações, os filtros e os snippets de consulta que você usará com frequência. Em seguida, procure métricas de “perigo” e use outras ferramentas para automatizar qualquer limpeza. Por exemplo, o comando wp transient delete WP-CLI pode ajudar você a eliminar transients indesejados no banco de dados.
De correções reativas à manutenção proativa do banco de dados
Os problemas de banco de dados que as agências enfrentam com mais frequência não são raros nem imprevisíveis. Eles são o resultado de padrões conhecidos. A diferença entre reagir a esses problemas e preveni-los está no foco.
Você não precisa inspecionar cada tabela nem auditar cada consulta. Precisa saber quais partes do banco de dados merecem atenção contínua e como identificar sinais de alerta precoces antes que se transformem em indisponibilidades ou chamados emergenciais de suporte.
Para agências de manutenção, isso muda a forma como o trabalho com banco de dados se encaixa no fluxo operacional. Em vez de tratar a limpeza do banco de dados como uma correção pontual após algo quebrar, ela passa a ser uma verificação leve e repetível.
Se você encontrar um problema de banco de dados que não consiga resolver, especialmente um que só aparece sob carga, ter o suporte certo faz diferença. Para sites hospedados na Kinsta, nossa equipe de suporte está disponível 24/7 para ajudar você.
