PrestaShop, layered_filter_block table grows too large

The PREFIX_layered_filter_block table is the query cache of the Faceted search module (ps_facetedsearch). Use the installation's real prefix: it is not always ps_.

Before clearing it, check the size of each table in phpMyAdmin and measure how it changes. The cache keys depend on the queries, filters and shop, language, currency and country contexts actually requested; the size of the catalogue alone does not prove where the growth comes from.

The cache was introduced in ps_facetedsearch 3.x, not in a particular version of the PrestaShop core. The published growth rates come from particular cases and should not be taken as the expected value for every shop.

Security update: ps_facetedsearch 3.0.0 to 4.0.3 is affected by GHSA-m5f5-28qr-9g9r. Update to 4.0.4 or later before clearing or automating the cache. If the shop ran an affected version, keep the logs and ask for an integrity review; emptying the table does not prove that the installation is clean.

Clear the measured cache

In Modules > Module Manager > Faceted search > Configure, use Clear cache. This action empties PREFIX_layered_filter_block.

PREFIX_layered_price_index is a different index. Rebuild it only if it is incomplete or out of date, and within a maintenance window; clearing the block cache does not by itself require the indexes to be regenerated. In InnoDB, reducing the logical size does not guarantee that the physical tablespace file shrinks either.

Check filters, prices, languages and currencies after clearing. Measure the table again to confirm that it was the one growing.

Automate only if it grows again

If you have confirmed recurring growth, copy the specific Flush block cache URL shown in the module's cron section. Do not copy the button's AJAX link or build the URL by hand. The token grants access to the task: treat it as a credential and do not publish it.

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

Set the frequency based on your measurements and keep the log for the first runs. A cron job that fails silently does not control the growth, nor does it replace investigating the traffic or configuration that generates so many keys.

Check the task and the growth

Before scheduling the example, create a private log directory outside the web root and replace the URL and the user. The URL may contain a token visible in the scheduled task and in process tools; limit access to that configuration.

A successful curl output does not prove that the module has emptied the cache: a redirect or an error page with a 200 code can look like a successful request. Check the response body and compare the table's size or row count before and after.

Avoid overlapping runs and adjust the frequency and log retention. If the keys are regenerated straight away, review requests, filters and contexts before increasing the clearing frequency; a cache that is constantly empty can raise the cost of browsing.