Solucionar problemas

PrestaShop, tamaño excesivo de la tabla layered_filter_block

Revisado el 4 min de lectura cache base de datos prestashop

La tabla PREFIX_layered_filter_block es la caché de consultas del módulo Búsqueda por facetas (ps_facetedsearch). Usa el prefijo real de la instalación: no siempre es ps_.

Antes de limpiar, comprueba en phpMyAdmin el tamaño de cada tabla y mide su variación. Las claves de caché dependen de las consultas, filtros y contextos de tienda, idioma, moneda y país realmente solicitados; el tamaño del catálogo por sí solo no demuestra el origen del crecimiento.

La caché se introdujo en ps_facetedsearch 3.x, no en una versión concreta del núcleo PrestaShop. Las tasas de crecimiento publicadas corresponden a casos particulares y no deben usarse como valor esperado para todas las tiendas.

Actualización de seguridad: ps_facetedsearch 3.0.0 a 4.0.3 está afectado por GHSA-m5f5-28qr-9g9r. Actualiza a 4.0.4 o posterior antes de limpiar o automatizar la caché. Si la tienda ejecutó una versión afectada, conserva registros y solicita una revisión de integridad; vaciar la tabla no demuestra que la instalación esté limpia.

Limpiar la caché medida

En Módulos > Gestor de módulos > Búsqueda por facetas > Configurar, usa Clear cache. Esta acción vacía PREFIX_layered_filter_block.

PREFIX_layered_price_index es un índice distinto. Reconstrúyelo solo si está incompleto o desactualizado y dentro de una ventana de mantenimiento; limpiar la caché de bloques no obliga por sí solo a regenerar los índices. En InnoDB, reducir el tamaño lógico tampoco garantiza que el fichero físico del tablespace disminuya.

Valida filtros, precios, idiomas y monedas después de la limpieza. Vuelve a medir la tabla para confirmar que era la que crecía.

Automatizar solo si vuelve a crecer

Si has confirmado un crecimiento recurrente, copia la URL específica Flush block cache que muestra el apartado cron del módulo. No copies el enlace AJAX del botón ni construyas la URL manualmente. El token concede acceso a la tarea: trátalo como una credencial y no lo publiques.

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

Define la frecuencia a partir de las mediciones y conserva el log durante las primeras ejecuciones. Un cron que falla en silencio no controla el crecimiento ni sustituye la investigación del tráfico o configuración que genera tantas claves.

Comprobar la tarea y el crecimiento

Antes de programar el ejemplo, crea un directorio de logs privado fuera de la raíz de la web y sustituye la URL y el usuario. La URL puede contener un token visible en la tarea programada y en herramientas de procesos; limita el acceso a esa configuración.

Una salida correcta de curl no demuestra que el módulo haya vaciado la caché: una redirección o una página de error con código 200 puede parecer una petición correcta. Revisa el cuerpo de la respuesta y compara el tamaño o recuento de la tabla antes y después.

Evita ejecuciones solapadas y ajusta frecuencia y conservación del log. Si las claves se regeneran enseguida, revisa peticiones, filtros y contextos antes de aumentar la frecuencia de borrado; una caché constantemente vacía puede elevar el coste de navegación.

También te puede ayudar

¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.