PrestaShop: tamanho excessivo da tabela layered_filter_block

A tabela PREFIX_layered_filter_block é a cache de consultas do módulo Faceted search (ps_facetedsearch). Use o prefixo real da instalação: nem sempre é ps_.

Antes de limpar, verifique no phpMyAdmin o tamanho de cada tabela e meça a sua variação. As chaves de cache dependem das consultas, filtros e contextos de loja, idioma, moeda e país realmente pedidos; o tamanho do catálogo, por si só, não demonstra a origem do crescimento.

A cache foi introduzida no ps_facetedsearch 3.x, não numa versão concreta do núcleo do PrestaShop. As taxas de crescimento publicadas correspondem a casos particulares e não devem ser usadas como valor esperado para todas as lojas.

Atualização de segurança: o ps_facetedsearch 3.0.0 a 4.0.3 está afetado por GHSA-m5f5-28qr-9g9r. Atualize para a 4.0.4 ou posterior antes de limpar ou automatizar a cache. Se a loja executou uma versão afetada, guarde os registos e peça uma revisão de integridade; esvaziar a tabela não demonstra que a instalação esteja limpa.

Limpar a cache medida

Em Modules > Module Manager > Faceted search > Configure, use Clear cache. Esta ação esvazia PREFIX_layered_filter_block.

PREFIX_layered_price_index é um índice diferente. Reconstrua-o só se estiver incompleto ou desatualizado e dentro de uma janela de manutenção; limpar a cache de blocos não obriga por si só a regenerar os índices. Em InnoDB, reduzir o tamanho lógico também não garante que o ficheiro físico do tablespace diminua.

Valide filtros, preços, idiomas e moedas depois da limpeza. Volte a medir a tabela para confirmar que era a que crescia.

Automatizar só se voltar a crescer

Se tiver confirmado um crescimento recorrente, copie o URL específico Flush block cache que a secção cron do módulo mostra. Não copie a ligação AJAX do botão nem construa o URL manualmente. O token concede acesso à tarefa: trate-o como uma credencial e não o publique.

curl --fail --silent --show-error --max-time 300 "URL_FLUSH_BLOCK_CACHE" >> /home/usuario_cpanel/logs/prestashop-facetas.log 2>&1

Defina a frequência a partir das medições e guarde o log durante as primeiras execuções. Um cron que falha em silêncio não controla o crescimento nem substitui a investigação do tráfego ou da configuração que gera tantas chaves.

Verificar a tarefa e o crescimento

Antes de agendar o exemplo, crie um diretório de logs privado fora da raiz do site e substitua o URL e o utilizador. O URL pode conter um token visível na tarefa agendada e em ferramentas de processos; limite o acesso a essa configuração.

Uma saída correta do curl não demonstra que o módulo tenha esvaziado a cache: um redirecionamento ou uma página de erro com código 200 pode parecer um pedido correto. Reveja o corpo da resposta e compare o tamanho ou a contagem da tabela antes e depois.

Evite execuções sobrepostas e ajuste a frequência e a conservação do log. Se as chaves se regenerarem logo, reveja pedidos, filtros e contextos antes de aumentar a frequência de eliminação; uma cache constantemente vazia pode aumentar o custo de navegação.