Dados de Autoload do WordPress: O que é e como limpá-lo

A Saúde do Site estava sinalizando um problema crítico em um dos meus sites por meses: Opções com autoload podem afetar o desempenho.

Eu ignorei. O site parecia bem.

Então alguém me perguntou por que o painel levava quase dez segundos para carregar quando a página inicial aparecia instantaneamente. Então, finalmente verifiquei o tamanho do autoload e encontrei megabytes de opções no banco de dados, a maioria escrita por plugins que eu havia desinstalado anos antes.

A parte frustrante é que a maioria dos conselhos sobre este tópico está desatualizada. O WordPress 6.6 mudou a forma como o autoload funciona, e a consulta que quase todos os guias ainda publicam agora retorna o número errado.

Muitos dos conselhos padrão de limpeza também não reduzem o tamanho do autoload, por razões ocultas no núcleo do WordPress.

Neste post, mostrarei o que são os dados de autoload do WordPress, como medi-los corretamente em uma instalação moderna, o que é seguro remover e como limpá-los sem quebrar seu site.

Aqui estão os principais pontos:

• Os dados de autoload são carregados em cada solicitação que chega ao WordPress, incluindo páginas de administração, chamadas REST e trabalhos cron, então o cache de página nunca o esconde de você.
• O WordPress sinaliza um problema crítico de Saúde do Site acima de 800 KB de opções com autoload, que é o mais próximo de um limite oficial que você encontrará.
• A consulta SQL na maioria dos guias agora subestima o total. O WordPress 6.6 substituiu os antigos valores de autoload sim/não por cinco valores possíveis, então filtrar por autoload='yes' perde as linhas mais novas.
• Limpar transientes expirados mal altera o tamanho do seu autoload. Transientes criados com uma data de expiração não são carregados automaticamente em primeiro lugar, e é por isso que plugins de limpeza de banco de dados parecem não fazer nada aqui.
• O verdadeiro inchaço são geralmente opções órfãs de plugins, deixadas para trás por plugins que você removeu anos atrás, já que nada as limpa automaticamente.
• O Otimizador de Banco de Dados do Duplicator mede o tamanho do autoload como parte de sua pontuação de saúde do banco de dados, o que o torna a maneira mais fácil de rastrear o número ao longo do tempo. Limpar opções com autoload ainda é um trabalho manual.
• Desativar o autoload é mais seguro do que excluir. Os dados permanecem no banco de dados caso um plugin precise deles, e a alteração é reversível.
• Nunca edite wp_options sem um backup atual. Você está trabalhando na única tabela que pode tirar todo o seu site do ar.
• Se o tamanho do autoload voltar a crescer em poucos dias após uma limpeza, um plugin o está reescrevendo a cada execução, e nenhuma quantidade de limpeza será suficiente.

Sumário

O que são Dados de Autoload no WordPress?

Todo site WordPress armazena suas configurações em uma tabela de banco de dados chamada wp_options. O URL do seu site está lá. Assim como sua lista de plugins ativos, configurações de tema e a configuração de quase todos os plugins que você instalou.

Cada linha nessa tabela tem uma coluna autoload. Essa coluna responde a uma pergunta: o WordPress deve carregar essa linha em todas as páginas, ou apenas quando algo a solicitar?

Quando a resposta é sim, a opção é carregada automaticamente (autoloaded). É só isso que o termo significa. Ela é carregada automaticamente, quer a página atual precise dela ou não.

O WordPress faz isso por um bom motivo. Em vez de executar uma consulta de banco de dados separada toda vez que um plugin solicita uma configuração, ele obtém todas as opções de autoload em uma única consulta no início da requisição e as mantém na memória. Uma consulta é melhor do que algumas centenas de pequenas.

Veja o que normalmente acaba armazenado como opções de autoload:

• Configurações principais sem as quais seu site não pode funcionar, como siteurl, home, active_plugins, template e stylesheet
• Configuração de plugins, frequentemente armazenada como um grande array serializado por plugin
• Chaves de licença e dados de ativação de plugins e temas premium
• Respostas de API em cache que um plugin salvou como uma opção regular em vez de um transient apropriado
• Restos de plugins que você removeu, que nada limpa por conta própria
• Transients criados sem tempo de expiração, que são carregados automaticamente por padrão

O design é bom. É o acúmulo que causa problemas.

Por que os Dados de Autoload Deixam Seu Site Lento?

Cada requisição que chega ao WordPress paga pelo seu tamanho de autoload. Isso afeta não apenas as visualizações de página dos visitantes, mas também as telas de administração, chamadas da API REST, trabalhos do WP-Cron, requisições AJAX e todas as tarefas em segundo plano que seus plugins disparam.

O custo não é apenas a consulta. Os valores das opções são armazenados serializados, então o PHP precisa desserializá-los todos na memória a cada carregamento. Uma tabela de autoload de 3MB significa que seu site reconstrói 3MB de arrays PHP antes de renderizar uma única palavra de conteúdo.

Isso é memória e CPU, a cada requisição, para sempre.

O cache de página não ajuda aqui. Um cache serve aos visitantes uma página HTML pronta, então essas requisições pulam o WordPress inteiramente. Suas próprias requisições não.

É aqui que uma tabela de autoload inchada aparece primeiro:

• wp-admin fica lento enquanto o front-end permanece rápido, já que as páginas de administração nunca são cacheadas
• O editor de blocos trava ao salvar ou carregar, pois cada requisição do editor passa por um carregamento completo do WordPress
• Carrinhos e checkout do WooCommerce ficam lentos, pois essas páginas são excluídas do cache por design
• Usuários logados têm um site mais lento do que todos os outros, o que torna o problema difícil de reproduzir
• Cron jobs se acumulam, pois cada um carrega o mesmo overhead

Se o seu host já lhe disse que o banco de dados parece bom enquanto o seu painel de controle trava, é geralmente por isso. O tamanho do autoload não aparece nas métricas que a maioria dos hosts verifica.

Quero ser honesto sobre o escopo, no entanto. O inchaço do autoload raramente é a única coisa que deixa um site lento, e limpá-lo não vai salvar um site com um host lento e imagens não otimizadas.

É apenas a parte que quase ninguém verifica, e ela cresce silenciosamente a cada mês que você mantém seu site funcionando.

Quanto Dado de Autoload no WordPress é Demais?

Pesquise esta pergunta e você obterá cinco respostas diferentes. Alguns guias dizem 300KB, outros dizem 1MB.

O WordPress 6.6 definiu o limite para todos. A Saúde do Site agora mostra um problema crítico quando o total de suas opções autoloaded excede 800KB.

Veja como eu interpreto os intervalos na prática:

• Abaixo de 800KB: saudável. A Saúde do Site fica quieta, e você não tem nada para perseguir.
• 800KB a 1MB: vale a pena dar uma olhada. Você está acima do limite principal, e geralmente é um ou dois plugins que estão causando isso.
• 1MB a 3MB: um problema real. Espere telas de administração visivelmente mais lentas, especialmente em hospedagem compartilhada.
• Acima de 3MB: algo está ativamente escrevendo lixo em uma programação, e a limpeza não vai adiantar até que você o encontre.

Você pode aumentar o limite com o filtro site_status_autoloaded_options_size_limit, mas isso apenas esconde o aviso. As consultas ainda são executadas com o mesmo tamanho.

O tamanho sozinho também não lhe diz tudo. Cem pequenas linhas órfãs valem menos da sua atenção do que um array serializado de 2MB de um plugin de slider que você parou de usar em 2022.

Persiga os maiores infratores, não a contagem.

Mais um bom comportamento que vale a pena saber: desde o WordPress 6.6, qualquer nova opção com mais de 150KB é definida para não carregar automaticamente por padrão.

O core tomou essa decisão porque opções autoloaded superdimensionadas eram um problema de desempenho muito comum. É filtrável através de wp_max_autoloaded_option_size, embora aumentá-lo seja uma má ideia.

Essa proteção só se aplica daqui para frente. Qualquer coisa que já esteja no seu banco de dados de antes ainda está sendo carregada automaticamente exatamente como sempre foi.

Por que a Maioria dos Guias de Autoload Agora Fornecem o Número Errado

Para a maior parte da história do WordPress, a coluna autoload continha um de dois valores: yes ou no. Simples. Cada tutorial já escrito sobre dados autoload se baseou nessa suposição.

O WordPress 6.6 o substituiu por cinco valores possíveis:

• on: explicitamente definido para autoload, e sempre será
• off: explicitamente definido para não carregar automaticamente, e nunca o fará
• auto: nenhuma preferência explícita foi dada, então o WordPress decide (e atualmente o carrega automaticamente)
• auto-on: o WordPress decidiu dinamicamente que ele deveria carregar automaticamente
• auto-off: o WordPress decidiu dinamicamente que não deveria, geralmente porque o valor é superior a 150KB

As linhas existentes não foram migradas. Opções criadas antes da mudança mantêm seus valores originais de yes e no, que o core trata como equivalentes a on e off.

Portanto, qualquer site que esteja rodando após a atualização 6.6 agora contém uma mistura de valores antigos e novos na mesma coluna.

Muitas pessoas dirão para você executar uma consulta filtrada por autoload='yes'. Em um site moderno, essa consulta ignora silenciosamente todas as opções gravadas desde a 6.6, juntamente com qualquer coisa do core marcada como auto ou auto-on.

Você obtém um número. Apenas não é o seu número, e é sempre muito baixo.

A correção é verificar contra todos os valores que o WordPress trata como autoload. O core expõe exatamente essa lista através de wp_autoload_values_to_autoload(), que retorna yes, on, auto-on e auto por padrão.

Qual Consulta SQL Você Deve Executar em Vez Disso?

Se você tem acesso ao phpMyAdmin ou à ferramenta de banco de dados do seu host, estas duas consultas lhe dirão quase tudo o que você precisa. Execute-as no banco de dados do seu site na aba SQL.

Antes de executar qualquer coisa no wp_options, crie um backup. Estas duas consultas apenas leem dados e não mudam nada, mas a próxima seção envolve a edição de linhas, e é melhor prevenir do que remediar.

Comece com o tamanho total do autoload:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,

COUNT(*) AS option_count

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Isso retorna o seu total em kilobytes junto com a contagem de quantas opções estão envolvidas. Compare-o com o limite de 800 KB da seção anterior.

Em seguida, descubra o que é o responsável:

SELECT option_name,

ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,

autoload

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')

ORDER BY LENGTH(option_value) DESC

LIMIT 20;

Isso lhe dá as vinte maiores opções autoloaded por nome, com seus tamanhos individuais e seu valor de autoload atual. Na maioria dos sites, as três ou quatro primeiras linhas respondem pela maioria do problema.

Duas coisas para observar antes de copiar estas:

• O prefixo da sua tabela pode não ser wp_. Muitas instalações usam algo personalizado por motivos de segurança. Verifique o wp-config.php para o valor de $table_prefix e substitua-o na consulta.
• Multisite funciona de forma diferente. Cada subsite tem sua própria tabela de opções (wp_2_options, wp_3_options, e assim por diante), além de uma tabela de rede wp_sitemeta. Você precisará verificá-las separadamente.

Se você preferir usar a linha de comando, WP-CLI cuida de ambos os trabalhos em uma linha cada. Isso retorna o seu total em bytes:

wp option list --autoload=on --format=total_bytes

E isso lista as opções autoloaded com seus tamanhos armazenados:

wp option list --autoload=on \

--fields=option_name,autoload,size_bytes \

--format=table

Nem todo mundo quer mexer em um console de banco de dados, e você não precisa. A próxima seção cobre duas rotas que permanecem dentro do painel do WordPress.

Como Verificar o Tamanho do Autoload do Seu WordPress?

Você não pode consertar o que não mediu, e você vai querer medir novamente após cada alteração que fizer.

Existem três maneiras de obter o número, dependendo de quão perto do banco de dados você quer chegar.

Opção 1: Saúde do Site (O Caminho Mais Rápido)

O WordPress já verifica isso para você. Vá para Ferramentas » Saúde do Site e abra a aba Status, depois procure por Opções autoloaded podem afetar o desempenho na lista.

Expanda-a e você obterá o seu tamanho total.

A pegadinha é que essa verificação só aparece quando você está acima de 800 KB. Silêncio não significa que você está em zero; significa que você está abaixo da linha. Ele também lhe dá um único instantâneo sem histórico e sem forma de agir sobre o que ele mostra.

Opção 2: Pontuação de Saúde do DB Optimizer (A Mais Fácil de Rastrear)

Se você quiser rastrear o tamanho do autoload ao longo do tempo em vez de verificá-lo uma vez, o DB Optimizer o coloca em um painel.

Abra o DB Optimizer e você obterá uma pontuação de saúde do banco de dados de 0 a 100. Cinco barras codificadas por cores detalham a pontuação: sobrecarga de tabela, transientes, revisões, tamanho do autoload e itens de lixo.

Deixe-me ser claro sobre o que isso faz e não faz. O DB Optimizer mede o tamanho do seu autoload e o relata. Ele não limpa opções com autoload.

Remover dados com autoload ainda é um trabalho manual, e eu o abordarei abaixo.

O que ele limpa são revisões de postagem, rascunhos automáticos, conteúdo lixeira, comentários de spam, transientes expirados, pingbacks, trackbacks e cache oEmbed. Esses realmente valem a pena limpar. Eles são apenas um problema diferente do autoload.

Antes de iniciar uma limpeza manual, não custa nada fazer uma limpeza rápida do banco de dados. Abra a guia Limpeza e execute todas as otimizações disponíveis.

Em seguida, vá para a guia Tabelas. Otimize todas as tabelas com sobrecarga.

Clique em Atualizar Pontuação no painel e observe o que acontece com o tamanho do autoload:

• A pontuação aumenta visivelmente: transientes não expirados fizeram parte do seu problema, e você limpou parte dele.
• A pontuação mal se move: seu inchaço são opções órfãs de plugins, e nenhuma ferramenta de limpeza tocará nisso. Vá direto para os métodos manuais.
• A pontuação aumenta e volta ao normal em poucos dias: um plugin ativo está reescrevendo opções com autoload a cada execução.

Esse último caso vale a pena ser detectado cedo. Ele evita que você limpe as mesmas linhas todo mês e se pergunte por que nada permanece.

O DB Optimizer também avisa quando você não tem um backup recente e vincula diretamente à criação de um. Ele é incluído gratuitamente nos planos Duplicator Pro e Elite, para que você possa manter seu site seguro e funcionando sem problemas.

Opção 3: Execute a Consulta Você Mesmo (O Mais Preciso)

Os comandos SQL e WP-CLI na seção anterior fornecem o número exato e a lista completa classificada, sem que nenhum limite oculte nada de você.

Esta é a rota que uso quando estou prestes a mudar algo, porque é a única que mostra o valor atual de autoload de cada linha. Você precisa disso antes de começar a editar.

Por que uma Limpeza de Banco de Dados Não Corrigiu o Tamanho do Seu Autoload?

Aqui está o conselho que você encontrará em quase todos os artigos sobre este tópico: limpe seus transientes, e o tamanho do seu autoload diminuirá.

Isso está em grande parte errado, e o núcleo do WordPress é onde você pode provar isso.

Veja o que `set_transient()` faz quando cria um transiente. Se você passar um tempo de expiração, o WordPress armazena esse transiente com autoload definido como falso. Apenas transientes criados sem data de expiração são carregados automaticamente, e essa é a minoria.

Transientes expirados são, por definição, transientes que tiveram uma expiração. Isso significa que eles nunca foram carregados automaticamente. Você pode excluir cinquenta mil deles, reduzir sua tabela wp_options em cem megabytes e mover seu número de autoload em quase nada.

Ambas as limpezas valem a pena. Uma tabela wp_options enorme deixa as consultas lentas, incha seus backups e faz com que as migrações falhem. É apenas um problema diferente com uma solução diferente, e confundir os dois é o motivo pelo qual tantas pessoas acham que seu plugin de limpeza está quebrado.

Então, o que resta quando os transientes se foram? Na minha experiência, é quase sempre um destes:

• Arrays de configurações serializadas de plugins que você desinstalou. A maioria dos plugins nunca se limpa após a exclusão, e essas configurações continuam sendo carregadas para sempre.
• Dados de licença e ativação de plugins premium, incluindo aqueles cujas licenças expiraram anos atrás.
• Respostas de API em cache armazenadas como opções simples em vez de transientes adequados, geralmente por plugins de feed social, análise ou SEO.
• Opções semelhantes a logs que crescem sem limites, onde um plugin anexa a uma única linha de opção a cada evento em vez de usar sua própria tabela.
• Transientes que não expiram, que são a exceção genuína aqui e o único tipo que uma limpeza de transientes ajudará.

Nenhum desses é resolvido com uma ferramenta de um clique. Essa é a resposta honesta, e é por isso que a próxima seção é prática.

Como Limpar Dados de Autoload do WordPress?

Não existe um plugin que resolva isso em um clique. Limpar opções autoloaded significa identificar linhas específicas e decidir o que fazer com cada uma.

Isso parece pior do que é. Na maioria dos sites, três ou quatro linhas respondem pela maior parte do problema, então você está tomando três ou quatro decisões em vez de centenas.

Aqui estão os três métodos, ordenados do mais seguro ao mais complexo:

• Desativar autoload para opções pesadas: alterna um único valor de coluna sem excluir nada, e é totalmente reversível.
• Excluir opções órfãs de plugins removidos: limpa permanentemente linhas deixadas para trás por plugins que se foram para sempre.
• Substituir o plugin que continua escrevendo: a única solução que se mantém quando algo está regenerando o inchaço a cada execução.

Faça um backup completo antes de iniciar qualquer um deles. Duplicator Pro cria uma cópia completa do seu banco de dados e arquivos em poucos minutos, e sua restauração de um clique significa que uma instrução UPDATE ruim custa dez minutos em vez do seu fim de semana.

Método 1: Desativar o Autoload para Opções Pesadas

Comece por aqui, porque nada é excluído. Você está alterando um valor de coluna e pode revertê-lo.

Pegue a lista dos principais infratores da sua consulta e trabalhe nela. Para cada opção grande, a questão é se o site precisa desses dados a cada carregamento de página.

Antes de desativar o autoload, verifique como e onde o plugin lê a opção. Alguns arrays de configuração são legitimamente necessários em requisições de front-end; outros são apenas para administração ou raramente acessados e são melhor carregados sob demanda.

Para impedir que uma opção seja carregada automaticamente, atualize seu valor de autoload:

UPDATE wp_options

SET autoload = 'off'

WHERE option_name = 'your_option_name_here'

AND autoload IN ('yes', 'on', 'auto', 'auto-on');

No WordPress 6.6+, use off. O WordPress também reconhece o valor legado no como não-autoloaded, então ele permanece compatível com instalações mais antigas.

O WP-CLI lida com isso em um comando e aceita on, off, yes ou no:

wp option set-autoload your_option_name_here off

Os dados permanecem exatamente onde estão. O WordPress simplesmente para de carregá-los a cada solicitação e os busca sob demanda quando algo chama get_option() em vez disso.

Após cada alteração, faça duas coisas: reexecute sua consulta de tamanho para confirmar que o número diminuiu e carregue seu front-end e o wp-admin para confirmar que nada quebrou.

Não agrupe vinte alterações e depois teste. Se algo der errado, você vai querer saber qual linha causou o problema.

Uma coisa a observar: se uma opção voltar a ser carregada automaticamente após uma atualização de plugin, esse plugin está reescrevendo o valor na ativação ou atualização. Sua alteração não falhou; ela foi sobrescrita.

Isso vale um ticket de suporte com os desenvolvedores do plugin e é um forte sinal de que você está caminhando para o Método 3.

Método 2: Excluir Opções Órfãs de Plugins Removidos

A exclusão é permanente, então este método requer mais cuidado do que o último.

Trabalhe em sua lista de principais infratores e associe cada nome de opção ao plugin que a criou. A maioria usa um prefixo reconhecível, embora nem todos sejam óbvios.

Pesquise o nome da opção antes de tocá-la, pois um nome que parece abandonado às vezes pertence a algo ainda em execução.

Em seguida, confirme se o plugin realmente foi removido.

Desativado não é removido. Um plugin desativado ainda tem seus arquivos no disco e retomará suas configurações quando você o reativar, portanto, excluir suas opções durante a desativação apenas perde sua configuração.

Antes de excluir uma opção, verifique se você segmentou a linha exata que pretende remover. Esta consulta somente leitura mostra o ID da opção, nome, status atual de autoload e tamanho armazenado sem alterar nada:

SELECT option_id, option_name, autoload, LENGTH(option_value) AS size_bytes

FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Quando tiver certeza, remova a linha:

DELETE FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Nunca execute um DELETE com um curinga LIKE nesta tabela, a menos que você tenha lido todas as linhas correspondentes primeiro. Um padrão que parece específico pode corresponder a muito mais do que você espera, e wp_options é a única tabela onde um erro derruba o site inteiro em vez de quebrar um recurso.

Quando você não consegue identificar uma linha de forma alguma, não a exclua. Mude seu autoload para desativado usando o Método 1 e deixe-a lá.

Você obtém o benefício total de desempenho, os dados sobrevivem e você pode reverter em segundos se algo precisar deles.

Este é o ponto em que o backup deixa de ser uma formalidade. Você está excluindo linhas da tabela mais importante do seu banco de dados WordPress, e o URL de recuperação de desastres do Duplicator Pro restaurará o site mesmo que uma consulta ruim bloqueie seu acesso ao wp-admin.

Método 3: Substituir o Plugin Que Continua Escrevendo Nele

Se o tamanho do seu autoload voltar a ultrapassar 1 MB dias após uma limpeza, pare de limpar. Algo está escrevendo ativamente a cada execução, e você fará isso para sempre.

Os suspeitos usuais, com base no que continuo encontrando:

• Plugins de slider e construtores de página que armazenam enormes arrays de configuração serializados
• Plugins de análise e estatísticas que registram em uma linha de opção em vez de sua própria tabela
• Plugins de segurança que mantêm logs de eventos como opções
• Gerenciadores de redirecionamento abandonados, onde cada regra de redirecionamento vive em uma opção crescente
• Plugins de feed social que armazenam em cache respostas de API como opções de autoload simples

Encontrar o culpado é mais fácil do que parece. Anote seus principais infratores, espere alguns dias e execute a consulta novamente. O que cresceu é a sua resposta.

Trocar um plugin em um site ativo é onde isso se torna arriscado, e é a única parte deste processo que eu nunca faria primeiro em produção.

O Duplicator Pro permite transformar qualquer backup completo do site em um site de staging em poucos cliques, sem uma conta de hospedagem separada ou transferências manuais de arquivos.

Teste a substituição lá, confirme se o site ainda funciona e o tamanho do autoload permanece estável, em seguida, faça a alteração na produção.

Como Impedir Que os Dados de Autoload do WordPress Voltem?

A limpeza não é um trabalho único, porque os dados de autoload do WordPress crescem como um efeito colateral da manutenção normal do site. Cada plugin que você tenta deixa algo para trás.

Alguns hábitos evitam que ele saia do controle novamente:

• Verifique sua pontuação mensalmente, ou após qualquer lote de alterações de plugins. O painel do DB Optimizer torna isso um trabalho de dez segundos, mas o Site Health funciona bem se você preferir não adicionar um plugin.
• Exclua plugins corretamente em vez de desativá-los. Desativar deixa todas as opções no lugar. Excluir pelo menos dá a um plugin bem construído a chance de limpar, embora muitos ainda não o façam.
• Verifique a opção antes de desinstalar. Se você sabe que um plugin deixa dados para trás, anote os nomes de suas opções enquanto ele ainda está instalado e é fácil de identificar.
• Instale menos plugins. É o conselho menos satisfatório nesta lista e o mais eficaz. Cada plugin que você não tenta é um dado de autoload que você nunca terá que limpar.
• Mantenha um backup atual em execução em uma programação, para que a limpeza do banco de dados seja uma decisão de baixo risco em vez de uma decisão nervosa.
• Monitore o Site Health em vez de esperar o site ficar lento. Quando você percebe a lentidão, geralmente já passou de 2 MB.

Perguntas Frequentes (FAQs)

Dados de Autoload do WordPress São um Hábito de Manutenção, Não uma Correção Única

O inchaço do autoload é o custo acumulado de cada plugin que seu site já tentou. Vale a pena pensar nisso, porque isso reformula o problema.

Não é um bug ou um sinal de que você fez algo errado. É o resíduo comum de executar um site WordPress por alguns anos, e nada no WordPress limpa isso para você.

Prefiro ser direto sobre o trabalho envolvido. Editar wp_options manualmente acarreta riscos reais, as ferramentas disponíveis medirão o problema mais prontamente do que o consertarão, e você estará de volta aqui em seis meses se continuar instalando plugins (o que você fará).

Defina um lembrete, verifique o número trimestralmente e trate-o como qualquer outra tarefa de manutenção.

Aqui está mais uma coisa que vale a pena fazer e que ainda não mencionei: verifique o tamanho do seu autoload bem antes de uma migração. É a maneira mais barata possível de encolher um arquivo de backup e reduzir o tempo de importação do outro lado.

Uma tabela wp_options inchada é uma das razões mais comuns para uma importação de banco de dados travar ou expirar em um novo host, e é genuinamente frustrante depurar uma migração falha. Dez minutos de limpeza antes de exportar salvam isso completamente.

Antes de Mexer em wp_options, Certifique-se de Que Seu Site Está Protegido

Limpar dados de autoload significa executar instruções UPDATE e DELETE na única tabela que pode tirar todo o seu site do ar. Um caractere curinga mal colocado em uma consulta, e você estará olhando para uma tela branca sem acesso ao wp-admin para corrigi-lo.

Duplicator Pro torna esse erro recuperável em vez de um desastre. Faça um backup completo antes de começar e restaure em minutos com um clique se algo der errado.

Seu URL de recuperação de desastres traz um site de volta mesmo quando o WordPress está completamente bloqueado, que é exatamente o cenário que uma consulta de banco de dados ruim cria. Experimente hoje mesmo!

Se este post fez você pensar sobre o que mais está no seu banco de dados, estes guias valem a pena ler em seguida.

• Como Excluir Todos os Transientes no WordPress (4 Métodos)
• Como Otimizar o Banco de Dados do WordPress: Tenha um Site Rápido em 10 Passos
• Limpeza do Banco de Dados do WordPress: Um Guia para Iniciantes para Remover o Lixo
• 7 sinais de aviso do banco de dados do WordPress que a maioria dos proprietários de sites ignora
• Como Corrigir um Banco de Dados Lento do WordPress: Um Checklist de 4 Passos
• Manutenção do Banco de Dados do WordPress: O Que Fazer Semanalmente, Mensalmente e Trimestralmente