Como limpar a tabela wp_options inchada (autoload)
O que é o autoload inchado no WordPress?
Na tabela de opções do WordPress, cada linha tem uma coluna autoload. As opções com autoload = yes são lidas de uma vez em cada carregamento de página, via a função alloptions. Quando plugins mal-comportados ou já removidos deixam megabytes de dados marcados como autoload, o WordPress passa a carregar tudo isso a cada requisição, e o site fica lento mesmo com pouca visita. Limpar esse autoload é o que devolve a performance.
Como identificar
- O site fica lento em todas as páginas, mesmo as simples, sem pico de tráfego que justifique.
- Uma consulta de tamanho mostra a opção alloptions com vários megabytes carregados por requisição.
- O Query Monitor aponta a query de opções (autoload) entre as mais pesadas do carregamento.
- A lentidão começou ou piorou depois de instalar e remover vários plugins ao longo do tempo.
Como prevenir
- Audite o tamanho do autoload periodicamente, antes que passe de 1 MB por requisição
- Prefira plugins que usam transients com expiração em vez de opções autoload permanentes
- Ao remover um plugin, confirme se ele limpou as próprias opções e apague as órfãs que ficaram
Causa
- Plugins gravando grandes blocos de dados (logs, caches, transients) com autoload = yes na tabela de opções.
- Plugins desinstalados que deixaram suas opções autoload órfãs para trás em vez de removê-las.
- Transients expirados acumulados que nunca foram limpos e continuam marcados como autoload.
- Configurações ou dados serializados enormes salvos numa única opção carregada em toda página.
- Falta de cache de objeto persistente, fazendo o WordPress reler a opção alloptions a cada requisição.
Como resolver
- Faça backup do banco antes de tudo: exporte o banco pelo phpMyAdmin. Você vai editar e apagar linhas da tabela de opções, então um backup é obrigatório antes de qualquer comando.
- Meça o tamanho do autoload: no phpMyAdmin (aba SQL), some o tamanho das opções autoload para saber o estrago. Acima de 1 MB já costuma pesar; vários MB indicam inchaço grave.
- Liste as maiores opções autoload: ordene as opções autoload por tamanho para identificar quem está inchando a tabela, normalmente um plugin específico ou transients antigos.
- Desligue ou apague o que não precisa carregar sempre: para opções de plugins ativos que não precisam ser globais, troque autoload para no; para órfãs de plugins removidos, apague a linha. Confirme a origem antes de remover.
- Adote um cache de objeto persistente: ative Redis ou Memcached para o WordPress não reler o alloptions do banco a cada página, aliviando o efeito do autoload.
-- 1) Tamanho total do autoload (rode no phpMyAdmin, aba SQL)
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';
-- 2) As 20 maiores opcoes carregadas em toda pagina
SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 20;
-- 3) Desligar o autoload de uma opcao (sem apagar o dado)
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'nome_da_opcao';
-- 4) Limpar transients expirados acumulados
DELETE FROM wp_options WHERE option_name LIKE '_transient_%';Perguntas frequentes
O que é o autoload na tabela de opções?
Quanto autoload é demais?
Posso simplesmente apagar todas as opções grandes?
Desligar o autoload de uma opção quebra o plugin?
Os transients contam no autoload?
Limpei o autoload mas o site continua lento. O que mais checar?
Como corrigir MySQL server has gone away
"MySQL server has gone away" aparece quando a conexão entre o WordPress e o MySQL cai antes da query terminar, geralmente por timeout de conexão ociosa ou por um pacote maior que o max_allowed_packet do servidor.
Como corrigir Error establishing a database connection
"Error establishing a database connection" significa que o WordPress não conseguiu falar com o MySQL. Quase sempre vem de credenciais erradas no wp-config.php, do servidor de banco fora do ar ou de tabelas corrompidas.
Como corrigir Table doesn’t exist após migração
O erro Table doesn't exist no WordPress aparece quando o site procura uma tabela do banco que não existe com aquele nome, quase sempre após uma migração. A causa típica é o prefixo de tabela do wp-config.php não bater com o prefixo real das tabelas importadas, ou um dump exportado de forma incompleta.
Como reparar tabelas corrompidas no WordPress
Reparar tabelas corrompidas no WordPress é o processo de consertar tabelas do banco MySQL/MariaDB que ficaram danificadas e pararam de responder. A corrupção costuma vir de queda de energia, disco cheio ou MySQL desligado no meio de uma escrita, e gera erros como "table is marked as crashed" e tabelas indisponíveis.
Como corrigir Max connections reached no MySQL
"Too many connections" acontece quando o MySQL atinge o limite de conexões simultâneas (max_connections) e recusa novas. No WordPress, isso derruba o site em picos de tráfego ou quando queries lentas seguram as conexões abertas.
Como corrigir erro de charset no banco de dados
O erro de charset do banco de dados no WordPress aparece quando o conjunto de caracteres da tabela não bate com o que o WordPress envia, fazendo acentos e emojis virarem símbolos como "é" ou "?". Costuma surgir após migrar o site ou importar um dump SQL no charset errado.
