Tabela wp_options

wp_options WordPress é a tabela central do banco de dados onde o CMS guarda configurações globais do site, opções de plugins e temas, dados de transients, e qualquer informação que precisa estar disponível em todo lugar do código. É carregada parcialmente em toda requisição via mecanismo de autoload, e por isso o tamanho e a saúde dessa tabela impactam diretamente o tempo de resposta de cada página. Em sites antigos sem manutenção, é comum a wp_options chegar a 50, 100, 200 MB e travar performance.

O que é a tabela wp_options

É uma das primeiras tabelas criadas pelo WordPress durante a instalação. Aparece com o prefixo configurado no wp-config.php (padrão wp_), e em sites multisite cada blog tem sua própria. Funciona como um repositório chave-valor: cada linha é uma opção identificada por nome único, com valor associado.

Na prática, qualquer setting administrativo do WordPress fica aqui. Nome do site, descrição, idioma, fuso horário, URL do site, formato de data, configurações de comentário. Todos guardados como linhas individuais na wp_options.

Plugins usam a tabela wp_options para persistir suas próprias configurações. Quando você instala WP Rocket, Yoast SEO ou Elementor, cada um cria dezenas de linhas com as opções daquele plugin: chaves de API, listas de exclusão, preferências de cache, configurações granulares. Combine com a função get_option e update_option, e o ciclo está completo.

Quem busca tabela wp_options costuma estar diagnosticando lentidão, tentando entender por que o site está pesado mesmo com plugin de cache, ou auditando após desinstalar plugins antigos. A maioria dos cenários converge para o mesmo culpado: opções deixadas para trás após desinstalação e crescimento descontrolado de transients.

Estrutura da wp_options

A tabela tem quatro colunas. option_id é o ID auto-incremental. option_name é o nome único da opção, como string. option_value é o valor armazenado, geralmente serializado em PHP quando é array ou objeto. autoload é o flag que define se essa opção deve ser carregada automaticamente em toda requisição.

O option_value pode armazenar quase qualquer coisa: string simples, número, array gigante, objeto serializado, JSON, dado binário. WordPress aceita 16 MB por linha por padrão. Plugins que armazenam logs ou caches gigantes na wp_options chegam a esse limite e quebram silenciosamente.

option_name segue convenção de nomeação por plugin: prefixo do plugin + identificador. wp_rocket_settings, yoast_settings, elementor_pro_license. Quem desenvolve plugins respeita esse padrão para evitar colisão. Quem não respeita gera bug em sites com vários plugins instalados.

O index principal é por option_name, o que torna lookup por nome instantâneo. Por isso get_option(‘site_name’) é operação rápida, mesmo em tabela com 10 mil linhas. O problema não é o lookup por nome; é o autoload, que carrega muitas linhas de uma vez.

Como otimizar wp_options

O primeiro passo é medir. Acesse o phpMyAdmin ou execute uma query SELECT no banco de dados do site. Procure o tamanho total da wp_options, o número de linhas e o tamanho do conjunto de linhas com autoload=yes. Esses três números mostram o estado da tabela.

Sites saudáveis têm wp_options com menos de 5 MB e menos de 1000 linhas. Sites com 10 MB já indicam plugins descuidados. Acima de 30 MB é problema sério: cada requisição carrega megabytes de configuração, mesmo que 95% disso não seja usado.

O segundo passo é limpar wp_options. Identifique opções de plugins desinstalados há tempo: linhas que começam com prefixos antigos, options de plugins que você não usa mais. Plugins como WP Optimize ou Advanced Database Cleaner listam essas opções e permitem deletar com segurança.

O terceiro passo é controlar transients. Transients expirados não são limpos automaticamente; ficam acumulando até alguém apagar. Em sites com muito tráfego, transients podem ser metade da tabela. Use WP-CLI ou plugin de limpeza para deletar transients expirados regularmente. Combine com transient WordPress bem usados para reduzir geração desnecessária.

Autoload e impacto na performance

Toda requisição WordPress executa SELECT option_value FROM wp_options WHERE autoload = ‘yes’ logo no início. O resultado é carregado em memória e disponibilizado para o resto do código via cache interno. Isso evita queries repetidas para opções comuns. O custo é que tudo com autoload=yes vira RAM em toda página carregada.

O autoload wordpress vira problema quando plugins guardam dados gigantes com flag yes. Logs serializados, listas de produtos, históricos de licenciamento. Cada um desses traz 1, 2, 5 MB para a memória em toda requisição. Em servidor com 64 MB de PHP por processo, sobra pouco para o resto.

Para identificar o problema, rode uma query: SELECT option_name, LENGTH(option_value) FROM wp_options WHERE autoload=’yes’ ORDER BY LENGTH(option_value) DESC LIMIT 20. Os 20 maiores autoloads aparecem ordenados, e geralmente o top 5 já explica a maior parte do problema.

A correção é mudar o flag autoload para no nas opções pesadas que não são usadas em toda página. UPDATE wp_options SET autoload=’no’ WHERE option_name=’nome_da_opcao’. Combine com cache bem configurado e operações via WP-CLI para tornar a manutenção segura e auditável.

Para times que querem manter a wp_options sempre saudável sem auditar manualmente toda semana, a FULL Services entrega o WP Optimize já licenciado e configurado dentro da stack profissional, com limpeza programada de transients expirados, alertas de autoload pesado e otimização periódica do banco. Em vez de auditar tabela manualmente, o site roda em uma camada de manutenção validada em produção.