A otimização do banco de dados do WordPress começa pela tabela wp_options, e não pelo botão de “otimizar tabelas”. Em toda requisição, o WordPress carrega para a memória, numa única consulta, todas as opções marcadas com autoload. Quando plugins deixam opções grandes ou esquecidas com autoload ligado, todas as páginas pagam essa conta, com cache ou sem. Desde o WordPress 6.6, a Saúde do Site avisa quando as opções com autoload passam do limite. Depois do autoload, vale olhar transients expirados, metadados órfãos, revisões, tabelas de log de plugins e índices que faltam. Meça primeiro com SQL ou WP-CLI, faça backup e limpe aos poucos.
A maioria dos bancos de WordPress lentos que encontro não é lenta por causa do tamanho. É lenta por causa de poucas coisas bem específicas: um blob de autoload que cresceu durante anos, um plugin gravando log no wp_options, uma consulta em postmeta sem índice que sirva. Um banco com um milhão de linhas pode ser rápido. Um pequeno com 4 MB de opções em autoload não é. Este artigo faz parte do meu guia sobre como acelerar o WordPress.
O que são os dados com autoload no wp_options?
Cada linha do wp_options tem uma coluna autoload. As linhas marcadas para autoload são buscadas juntas logo no início de toda requisição e ficam no cache alloptions, então as chamadas seguintes a get_option() não vão ao banco. Para configurações pequenas que o site inteiro usa, como a URL do site ou a lista de plugins ativos, é um bom desenho.
O problema começa quando um plugin coloca em autoload algo grande que só uma tela do admin usa: um cache serializado, uma lista com todos os produtos, saída de debug. Com object cache persistente, o array alloptions inteiro vira uma única entrada no cache, e um array grande passa a custar memória e transferência em toda requisição. E remover um plugin muitas vezes deixa as opções dele para trás, ainda com autoload.
O WordPress 6.6 mudou esse funcionamento. A coluna autoload agora aceita on, off, auto, auto-on e auto-off, além dos antigos yes e no. Quando o plugin não diz se a opção deve ter autoload, o WordPress decide, e opções grandes deixaram de ter autoload por padrão. A Saúde do Site também ganhou uma verificação que acusa quando o tamanho total das opções com autoload passa de um limite, e esse limite pode ser alterado por filtro.
Como medir as opções com autoload?
Comece pela Saúde do Site, em Ferramentas. Se ela aponta as opções com autoload como problema, você já sabe onde procurar. Para ter números, use SQL. Troque wp_ pelo prefixo das suas tabelas (o comando wp db prefix mostra qual é). A lista do IN cobre os valores do 6.6 e o antigo:
-- Tamanho total das opções com autoload
SELECT COUNT(*) AS opcoes, ROUND(SUM(LENGTH(option_value)) / 1024) AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');
-- As 20 maiores opções com autoload
SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb, autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;Dá para rodar essas consultas com wp db query "..." ou em qualquer cliente MySQL. O nome da opção quase sempre entrega o plugin dono: prefixos como wpseo_, elementor_ ou woocommerce_. Qualquer coisa com prefixo de um plugin que você não usa mais é candidata à limpeza.
Como corrigir opções grandes com autoload?
Para cada opção grande, você toma uma de três decisões:
- Ela é de um plugin removido. Apague, depois do backup.
- Ela é de um plugin ativo, mas não é usada em toda página. Desligue o autoload e teste as telas que esse plugin usa.
- Ela é usada em todo lugar e é grande porque o plugin não para de aumentá-la. Reporte ao autor ou troque o plugin. Desligar o autoload só muda a consulta de lugar.
O WP-CLI resolve cada caso sem SQL escrito à mão:
# Sempre primeiro
wp db export antes-da-limpeza.sql
# Ver e mudar o autoload de uma opção
wp option get-autoload cache_de_algum_plugin
wp option set-autoload cache_de_algum_plugin off
# Apagar uma opção deixada por plugin removido
wp option delete configuracoes_plugin_antigo
# Limpar o object cache depois de mudanças diretas
wp cache flushNo código, quem desenvolve plugin tem a função wp_set_option_autoload() desde o WordPress 6.4, além do argumento $autoload de add_option() e update_option(). Se você cria plugins, passe false para tudo que não é necessário na maioria das requisições.
O que mais deixa o banco do WordPress lento?
Com o autoload sob controle, estes são os próximos itens que confiro, na ordem em que costumam fazer diferença:
| Problema | Como verificar | O que fazer |
|---|---|---|
Transients expirados acumulados no wp_options | wp transient list --format=count | wp transient delete --expired; com object cache persistente, os transients saem da tabela |
| Consultas lentas de plugins | Query Monitor, slow query log do MySQL | Corrigir ou trocar o plugin, criar índice quando o padrão da consulta justificar |
| Tabelas de log e estatística de plugins | wp db size --tables | Definir período de retenção no plugin ou apagar linhas antigas |
| Histórico do Action Scheduler no WooCommerce | Tamanho das tabelas actionscheduler, quantidade de ações falhas e pendentes | Corrigir primeiro as ações que falham e deixar a retenção limpar as concluídas |
| Post meta órfão | A consulta abaixo | Apagar depois do backup |
| Revisões sem limite | wp post list --post_type=revision --format=count | Definir WP_POST_REVISIONS; apagar revisões antigas se o número for enorme |
| Tabelas em MyISAM | SHOW TABLE STATUS | Converter para InnoDB numa janela de manutenção |
Post meta órfão é metadado de um post que não existe mais. Esta consulta conta quantos são:
SELECT COUNT(*)
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;Para consultas lentas, a fonte honesta é o slow query log do MySQL. O Query Monitor mostra as consultas da página que você está vendo. O slow log mostra o que dói no tráfego todo, incluindo cron e chamadas REST. Ligue com slow_query_log, ajuste long_query_time para um limite que faça sentido no seu servidor e leia o log depois de um dia normal.
Em sites grandes, principalmente WooCommerce, os índices padrão do WordPress em wp_postmeta e wp_usermeta não atendem todos os padrões de consulta. O plugin Index WP MySQL For Speed cria índices pensados para consultas comuns do WordPress. Rode EXPLAIN nas suas consultas lentas antes e depois, para saber se mudou alguma coisa no seu caso.
Plugins ajudam na otimização do banco de dados do WordPress?
Para a parte rotineira, sim: transients expirados, revisões, comentários de spam, lixeira. O que eles não conseguem é decidir se uma opção de 900 KB pertence a um plugin que você ainda usa. Isso exige alguém lendo nomes de opções. Eu também tomaria cuidado com qualquer recurso de “otimizar tabelas” em tabelas InnoDB grandes. O OPTIMIZE TABLE reconstrói a tabela, o que pode demorar e travar gravações num site movimentado. O wp db optimize faz a mesma coisa pela linha de comando. Se for rodar, rode em horário de pouco acesso. Recuperar espaço em disco raramente muda o tempo de resposta.
Como o banco se relaciona com o cache?
O cache de página esconde os problemas do banco para o visitante anônimo. Por isso tanto site parece rápido no PageSpeed e se arrasta no wp-admin. Um Redis object cache no WordPress corta as consultas repetidas para todo o resto, mas não resolve uma consulta que já é lenta na primeira vez, e guarda o blob alloptions do jeito que ele está. Limpe o banco e depois coloque em cache. Para entender qual camada de cache cuida de quê, leia cache de página vs object cache vs edge cache.
O tempo gasto no banco aparece no tempo de resposta do servidor. Depois da limpeza, meça o TTFB em URLs sem cache e no wp-admin, como explico no guia de TTFB no WordPress.
Perguntas frequentes
Qual deve ser o tamanho das opções com autoload?
O menor que o site precisar. O aviso da Saúde do Site é um teto útil, não uma meta. Na prática, olho primeiro as maiores opções individuais, porque uma ou duas delas costumam responder pela maior parte do total.
Posso desligar o autoload de todas as opções?
Pode, mas fica pior. As opções que toda requisição usa passariam a ser buscadas uma consulta de cada vez. O autoload é um bom mecanismo que alguns plugins usam mal. Corrija os pontos fora da curva.
É seguro apagar opções de plugins removidos?
Em geral, sim, mas confirme que o prefixo é mesmo de um plugin que você removeu, porque alguns plugins dividem prefixo com add-ons. Exporte o banco antes e teste o site depois.
Se o wp-admin está lento, o banco sempre volta como suspeito e você quer a causa encontrada e documentada antes de alguém mexer em produção, esse é o trabalho que faço na auditoria de performance WordPress. Quando as correções exigem mão no servidor, a equipe da WebOption faz a implementação.