Filtros lentos con miles de combinaciones: culpa de MariaDB

En octubre de 2026, Gustavo, de la comunidad, pidió a la IA que le optimizara una tienda con unas 40.000 combinaciones en la que el módulo de filtros tardaba 6 segundos en cargar una categoría. El hallazgo no estaba en PrestaShop, sino en la base de datos. Respuesta corta: en MariaDB 10.3 o superior, la optimización split_materialized puede convertir una consulta de filtros de 0,15 segundos en una de más de 5 minutos cuando hay productos con miles de combinaciones. Apagarla solo en esas consultas lo arregla.

Qué pasa

MariaDB trae encendida desde la 10.3 una optimización llamada split_materialized (en los planes de ejecución aparece como LATERAL DERIVED). En las consultas del buscador por facetas casi siempre ayuda.

El problema llega cuando el filtro es de un grupo de atributos que usa un producto con cientos o miles de combinaciones. Entonces la subconsulta de productos se recalcula una vez por cada combinación, y el coste crece con el cuadrado del número de combinaciones.

Los números del caso: el filtro «Tamaño» de una categoría con productos de 4.016 y 8.032 combinaciones pasaba de 0,15 segundos a más de 5 minutos.

Cómo comprobar si te pasa

1. Mira qué base de datos tienes: SELECT VERSION();. Si es MySQL, esto no te afecta (no tiene esa opción); si es MariaDB 10.3 o superior, sigue.
2. Activa el registro de consultas lentas y abre la categoría y el filtro que van lentos. Copia la consulta de filtros que aparezca.
3. Ejecútala dos veces en una copia, con la optimización y sin ella:

SET SESSION optimizer_switch = 'split_materialized=off';
-- ejecuta aquí la consulta lenta del filtro y mide el tiempo
SET SESSION optimizer_switch = 'split_materialized=default';

Con SET SESSION el cambio solo afecta a tu conexión, así que puedes probar sin tocar al resto de la tienda.

Cómo aplicarlo

• Solo donde hace daño (lo que hizo Gustavo): un override del módulo de filtros que apaga la optimización en la sesión antes de las consultas de facetas con grupos de atributos pesados y la deja como estaba después. El resto de consultas de la tienda siguen aprovechándola.
• Para todo el servidor, con optimizer_switch en la configuración de MariaDB. Es más sencillo, pero afecta a todas las consultas: mide antes y después las páginas importantes, no solo la categoría lenta.

En un hosting compartido normalmente no puedes tocar la configuración global, y la vía de la sesión es la única.

Las combinaciones salen caras en todas partes

En la misma tienda apareció otro síntoma del mismo origen: el módulo de un servicio externo de marketing, si había un producto en el carrito, leía sus 2.000 combinaciones en cada página. Un producto con miles de combinaciones castiga a los filtros, a los feeds, a los conectores y a cualquier módulo que las recorra.

Si tu catálogo tiene productos así, valora si todas esas combinaciones tienen que ser del mismo producto. A veces es mejor separarlos en productos simples y mostrarlos agrupados en la ficha, como hace el módulo de productos simples como si fuesen combinaciones de Rekire. Y para localizar qué consultas y qué módulos pesan en cada página, está RKR Diagnoses.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación