Você já sentiu aquele calafrio ao abrir o phpMyAdmin e ver mais de 500 consultas por segundo em um site que deveria ser modesto?
Eu já. Era uma tarde de terça-feira. Um cliente, gestor de um portal de notícias com tráfego mediano (~50k visitas/dia), me ligou desesperado. O site estava respondendo em 8 segundos. Core Web Vitals? Vermelho total. O pior: a equipe de desenvolvimento já tinha otimizado imagens, implementado cache em página, até migrado para um servidor dedicado com NVMe. Nada adiantava.
Comecei a suar. Literalmente: a temperatura da sala subiu com o estresse. Fui direto ao coração da besta: o banco de dados. Liguei o SHOW PROCESSLIST e vi um monte de consultas em estado Waiting for table_open_cache. O que era aquilo? Um fantasma sugando performance.
Bem-vindo ao submundo esquecido do MySQL no WordPress. O table_open_cache. Um parâmetro minúsculo, ignorado por 99% dos guias de performance, e que pode ser o assassino silencioso do seu TTFB. Vamos abrir este dossiê investigativo.
A Cena do Crime: O que é o table_open_cache e por que ele importa?
Toda vez que o WordPress executa uma consulta — seja para listar posts, buscar metadados ou contar comentários — o MySQL precisa abrir a tabela correspondente. Essa abertura tem um custo. Para evitar abrir e fechar tabelas a cada consulta, o MySQL mantém um cache de descritores de tabelas abertas. Esse cache é controlado pelo parâmetro table_open_cache.
Quando o cache é grande o suficiente para conter todas as tabelas usadas simultaneamente, as consultas voam. Quando não… bem, é aí que o fantasma aparece: Waiting for table_open_cache é um evento de espera (wait event) que indica que uma thread está esperando o sistema liberar um slot no cache para abrir uma tabela. Imagine um estacionamento lotado: você precisa que alguém saia para você entrar. Agora multiplique isso por centenas de consultas concorrentes.
O Diagnóstico: Como Descobri o Assassino
Naquele servidor do cliente, o table_open_cache estava configurado com o valor padrão de 2000. Parece muito, certo? Errado. O site tinha 74 plugins ativos, mais de 200 tabelas no banco (entre WordPress core, WooCommerce, Yoast, etc.). Em pico de tráfego, o MySQL precisava abrir cerca de 300 tabelas diferentes por segundo. Com o cache limitado, as threads competiam por slots, gerando filas de espera.
Liguei o SHOW ENGINE INNODB STATUS e vi dezenas de threads presas em table_open_cache. A solução foi aumentar o cache para 4096 (2x o padrão) e, mais importante, reduzir o número de tabelas abertas desnecessariamente — eliminando plugins que criavam tabelas próprias sem necessidade real. Resultado: tempo de resposta caiu de 8s para 1,2s. Tudo por um ajuste ignorado.
O Estudo de Caso Reverso: O Site que Morreu por Excesso de Cache
Sim, o título não é ironia. Excesso de cache também pode matar. Um cliente (agência de design) tinha um site com 10 artigos, 5 páginas, 3 plugins. O table_open_cache estava em 8192 (altíssimo). O MySQL consumia 2GB de RAM à toa, pois o cache muito grande fazia o banco alocar memória desnecessariamente, deixando menos RAM para o PHP e o Redis. Resultado: lentidão geral.
Reduzi para 1024. Performance melhorou. A lição: não existe bala de prata. O valor ideal depende do número de tabelas abertas simultaneamente. Use o comando SHOW GLOBAL STATUS LIKE 'Open_tables' para ver quantas tabelas estão abertas agora, e SHOW GLOBAL STATUS LIKE 'Opened_tables' para ver quantas foram abertas desde o início. Se Opened_tables for muito maior que Open_tables, seu cache está estourando.
A Fórmula Secreta (que ninguém conta)
Para WordPress, uma boa métrica é: table_open_cache = (número de tabelas do banco) * (número de consultas simultâneas esperadas) * 1.5. Mas isso é só um chute. O ideal é monitorar os wait events: se table_open_cache aparece no topo do performance_schema, aumente o cache gradualmente até o evento sumir. Cuidado com o consumo de RAM: cada slot do cache usa aproximadamente 400 bytes. 4096 slots = 1.6MB. Irrisório. Mas há overhead de gerenciamento. Fique atento.
Manifesto Técnico: Por que o Mercado Ignora Isso?
Chefes de SEO, agências de performance, consultores de WordPress — todos focam em cache de página, CDN, compressão de imagens. Raramente alguém abre o MySQL para ver os wait events. É um trabalho de detetive. E dói. Porque exige acesso SSH, conhecimento de performance_schema e paciência para interpretar logs. Mas o ganho é brutal: redução de 30-50% no tempo de consulta em sites com muitos plugins.
E o pior: muitos hosts compartilhados bloqueiam o acesso a essas variáveis. O cliente médio nunca vai saber. Mas você, que leu até aqui, agora tem o mapa do tesouro. Aplique, meça, e veja o Core Web Vitals dançar.
Última dica: depois de ajustar, não esqueça de reiniciar o MySQL (ou ao menos fazer FLUSH TABLES). E nunca, jamais, aumente o cache sem monitorar a memória. Um servidor com 1GB de RAM não aguenta 8192 slots.
Essa é a verdade nua e crua. Se você quer ser elite, desça até o banco. O fantasma está lá, esperando.