Una tienda PrestaShop en producción desde hace cinco años raramente pesa menos de 6 GB en base de datos. Muchas superan los 12 GB. No es el catálogo el que explota — un catálogo de 10 000 productos con declinaciones, imágenes y SEO completo cabe en un gigabyte. Lo que se hincha son las tablas ballast: tablas técnicas que PrestaShop alimenta continuamente y que ningún proceso nativo limpia. Al cabo de cinco años, representan a menudo del 70 al 90 % del peso total de la BDD.
Este artículo cartografía las tablas culpables, da las consultas SQL para medir la ganancia potencial y explica cómo implementar una política de retención duradera sin romper la tienda. No un checklist de revista — la versión que se aplica realmente en producción.
Por qué una base PrestaShop se hincha sin ruido
PrestaShop no tiene garbage collector. Todas las tablas que registran eventos — búsquedas internas, conexiones, carritos abandonados, logs, metadatos huérfanos — crecen linealmente, a veces exponencialmente, sin que ningún mecanismo nativo desencadene una limpieza.
Concretamente, en una tienda con 2 000 visitantes/día:
ps_statssearchrecibe de 300 a 800 líneas por día (cada búsqueda interna, incluso vacía).ps_connectionsyps_connections_pageregistran cada visita y cada página vista. Cuente de 5 000 a 15 000 líneas por día.ps_guestcrea un registro para cada visitante no autenticado.ps_cartguarda todos los carritos — abandonados incluidos — para siempre. En algunas tiendas, encontramos un 90 % de carritos vacíos que datan de 2018.ps_logcaptura todos los errores y eventos admin.
Multiplique por 365 días y 5 años: hablamos de decenas de millones de líneas para un volumen de negocio nulo. El peso bruto no es el peor problema. El verdadero coste está en otra parte.
El coste oculto de las tablas ballast
1. Rendimiento de las consultas
InnoDB carga los índices en memoria (buffer pool). Cuando las tablas técnicas de varios GB monopolizan el buffer, sus consultas de catálogo, carrito y pedido se vuelven más lentas. El LCP de una ficha producto puede tomar de 200 a 400 ms adicionales únicamente a causa de la presión memoria MySQL.
2. Copias de seguridad y restauraciones
Un dump mysqldump de 12 GB tarda de 30 a 60 minutos según el disco. La restauración puede tardar de 2 a 4 horas. Si la copia de seguridad automática de su hosting supera una ventana horaria, comienza a fallar en silencio. Muchas tiendas descubren que ya no tienen copia válida el día de un incidente.
3. Migraciones bloqueadas
Migrar una tienda 12 GB en PHP 8.2 hacia un nuevo servidor, o en PrestaShop 9, exige transferir el dump por rsync, restaurar, probar. El peso multiplica cada operación. Las migraciones «simples» se vuelven proyectos de varios días.
4. Módulos de terceros que se cargan
Ciertos módulos de estadísticas, marketing, conectores ERP crean sus propias tablas y las dejan crecer indefinidamente. ps_netreviews_, ps_advancedstats_, ps_mailchimp_ son sospechosos frecuentes. Una auditoría revela a menudo una tabla de 2 GB dejada por un módulo desinstalado hace dos años.
Auditoría: cuánto pesa realmente su base
Antes de toda limpieza, se mide. Esta consulta lista las tablas de su base clasificadas por tamaño decreciente:
SELECT
table_name AS 'Table',
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size (MB)',
table_rows AS 'Rows'
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 30;Generalmente se obtiene un ranking que se parece a:
ps_statssearch— 1,8 GBps_connections_page— 1,2 GBps_pagenotfound— 800 MBps_connections— 600 MBps_log— 400 MBps_cart— 350 MBps_guest— 300 MBps_cart_rule+ps_cart_cart_rule— 250 MB
Note que ps_product, ps_product_lang, ps_orders aparecen raramente en el top 10. El dato de negocio real es minoritario en una base PrestaShop antigua.
Cartografía de las tablas ballast y política de retención
ps_statssearch — las búsquedas internas
Esta tabla registra cada palabra introducida en la barra de búsqueda. Conservar el historial más allá de 90 días no tiene ningún interés analítico: las tendencias de búsqueda de 2019 no aclaran nada en 2026. Política recomendada: retención 90 días.
-- Auditoría
SELECT COUNT(*) AS total, MIN(date_add) AS mas_antiguo
FROM ps_statssearch;
-- Supresión más allá de 90 días
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_connections y ps_connections_page — el historial de visita
Si usa GA4 o Matomo, estas tablas son redundantes. PrestaShop las llena para su propio módulo de estadísticas que nadie consulta. Política: retención 30 días, o 0 si tiene una herramienta externa.
ps_pagenotfound — los 404
Útil para identificar los enlaces rotos y programar redirecciones 301. Pero tras tratamiento, el historial ya no sirve. Política: retención 60 días, tras extracción de los 404 recurrentes.
ps_cart — los carritos abandonados
Sutil. Los carritos recientes sirven para el retargeting y las recuperaciones. Más allá de 90 días, un carrito abandonado está estadísticamente perdido. Política: conservar 90 días, pero no tocar los carritos vinculados a pedidos (tabla unida ps_orders.id_cart).
-- Supresión segura: únicamente los carritos SIN pedido asociado
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_guest — los visitantes no autenticados
Vinculada a ps_customer y ps_connections. Limpieza con precaución: un guest convertido en customer debe ser preservado. Política: suprimir los guests sin customer y sin conexión reciente.
ps_log — los logs admin
Útil para el debug reciente, sin valor pasado un mes. Política: retención 30 días.
Metadatos huérfanos
Cuando suprime un producto, ciertas tablas vinculadas guardan líneas huérfanas: ps_image, ps_feature_product, ps_specific_price, ps_product_attachment. Idem para las categorías, fabricantes, proveedores suprimidos. Estas líneas no sirven para nada y falsean los joins.
-- Ejemplo: ps_image huérfanas
SELECT i.id_image FROM ps_image i
LEFT JOIN ps_product p ON p.id_product = i.id_product
WHERE p.id_product IS NULL;La trampa del DELETE en producción
Suprimir un millón de líneas en una sola consulta sobre una tabla InnoDB bloqueada por su admin y su front, es la garantía de un crash. El binary log explota, la replicación se cae, el servidor puede irse en swap.
La regla absoluta: suprimir por lotes de 5 000 a 10 000 líneas máximo, con una pausa de 100 ms entre cada lote.
-- Bucle de supresión por lotes (pseudo-código)
DO WHILE rows_affected > 0:
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY)
LIMIT 5000;
SLEEP 0.1;
END DO;Y sistemáticamente: dry-run antes de execute. Quiere saber cuántas líneas van a desaparecer y cuánto espacio recupera antes de clicar.
Automatizar la retención: la estrategia correcta
Hacer la limpieza a mano una vez y olvidarla no sirve para nada — la base se rehinchará. La retención debe ser continua y automática:
- Cron diario que ejecuta la política de retención de cada tabla.
- Token de seguridad para que el cron no sea desencadenable desde el exterior.
- Logs de ejecución para seguir lo que se ha suprimido.
- Notificación en caso de fallo o anomalía (volumen anormal de supresión).
- OPTIMIZE TABLE semanal sobre las tablas limpiadas para recuperar el espacio disco (sino InnoDB conserva el espacio asignado).
Nuestro módulo dfcleanup: el método empaquetado
Implementar esta estrategia a mano exige de dos a tres días de dev y otros tantos de tests. Nuestro módulo dfcleanup para PrestaShop 8 y 9 industrializa todo el método descrito aquí:
- Seis limpiadores especializados: búsquedas, carritos, logs, estadísticas, metadatos huérfanos, imágenes huérfanas. Cada uno con su propia retención configurable.
- Tres modos: Auditoría (solo lectura), Dry-run (simulación trazada), Execute (supresión por lotes de 5 000 líneas).
- Ganancia en MB calculada antes de la acción, por cleaner y total.
- Tarea cron asegurada por token, lista para usar.
- Logs detallados y compatibilidad PrestaShop 8 y 9.
Por 19 €, evita las consultas DELETE a mano e instala una política de retención duradera. Comparado con el tiempo de dev y el coste de un incidente DBA, es uno de los módulos con el mejor ROI del catálogo.
FAQ
¿Hay que hacer un OPTIMIZE TABLE después de cada DELETE?
No, no después de cada DELETE — es costoso en I/O y bloquea la tabla. Una vez por semana o por mes, en horas valle, sobre las tablas que han sufrido una limpieza masiva. OPTIMIZE TABLE recupera el espacio disco que InnoDB no libera naturalmente tras supresión.
¿La limpieza puede afectar al SEO o a las estadísticas?
Ningún impacto SEO: las tablas limpiadas son técnicas (búsquedas internas, conexiones, logs), no el catálogo ni la URL. Del lado stats, si usa GA4 o Matomo, sus datos están almacenados con ellos — la BDD PrestaShop es redundante. Si usa las estadísticas nativas PS, configure una retención más larga (180 días por ejemplo).
¿Qué retención para los carritos abandonados?
90 días son ampliamente suficientes. Las herramientas de recuperación de carrito (mail, retargeting) se activan en 24 a 72 horas. Más allá de 90 días, la probabilidad de recuperación es estadísticamente nula. Y nunca suprime un carrito convertido en pedido — el join ps_orders.id_cart protege este dato.
¿Cuánta ganancia esperar concretamente?
En una tienda de 5 años, 2 000 visitantes/día, medimos en promedio del 60 al 80 % de reducción de la BDD en el primer paso. Una tienda a 12 GB vuelve a bajar a 3 o 4 GB. Los pasos siguientes estabilizan la base a un nivel próximo al «peso de negocio real».
¿El módulo es compatible multi-tienda?
Sí. Los limpiadores respetan el perímetro multi-shop cuando es pertinente (carritos, búsquedas por tienda). Las tablas globales (logs, conexiones) se limpian globalmente.
Para ir más lejos
La deuda de base es una de las tres fuentes principales de degradación performance a largo plazo de una tienda PrestaShop, con los módulos de terceros obsoletos y las imágenes mal optimizadas. Vea también nuestro checklist Core Web Vitals 2026 para el resto del cuadro, y la guía PrestaShop 9 vs 8 si prepara una migración: aligerar la BDD antes de la migración puede dividir por 5 el tiempo de báscula.