Era uma tarde de sexta-feira. O cliente jurava que o site estava lento. Olhei o wp_options — 37 mil registros. O Apache estava engasgando.
Não, não é overclock de servidor é sobre a estrutura interna que ninguém debuga.
O problema oculto: cache de tabelas e transiente maldito
A tabela wp_options armazene opções, transientes e bloqueios de sessão. Quando ela cresce além de 1.000 registros, o MySQL começa a sofrer com table scans. Com mais de 3.000? Cada requisição ao painel ou ao front-end pode gerar lock de tabela MyISAM (sim, ainda usado em muitos hosts).
Como o Apache entra nessa?
O Apache, com seu modelo de processos filhos, faz requisições paralelas. Se uma trava na wp_options segura um cache, todos os workers ficam esperando — e o servidor parece morto.
Exemplo real: um site com 39.472 registros em wp_options onde 34.000 eram transientes expirados (plugins de cache, WooCommerce). A queda de QPS foi de 45 para 3.
A solução reversa: limpeza cirúrgica com SQL
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_value < NOW() - INTERVAL 1 DAY;Esse comando remove transientes expirados. Mas cuidado: nunca faça sem backup em produção.
Impacto real
- Redução de 37k para 2.1k registros no wp_options
- Tempo de consulta ao banco caiu de 2.3s para 0.2s
- Apache voltou a ter workers livres — site speed dobrou
O erro clássico: plugins mal codificados não limpam transientes. Visual Composer e WooCommerce são os maiores vilões.
E a licença GPL?
A licença GPL permite que você modifique o WordPress e seus plugins. Mas se você distribuir um tema com código modificado sem manter a licença, perde o direito. No contexto de performance, muitos copiam soluções de cache sem entender que estão causando o oposto do que querem.
Respeite a GPL, mas também respeite o banco de dados.
Antes de culpar o servidor, investigue o wp_options. A resposta pode estar a um SQL com DELETE.