# Por qué su base PrestaShop pesa 8 GB en 2026: auditoría, limpieza y estrategia de retención de las tablas ballast > Una tienda PrestaShop activa 5 años pesa de 6 a 12 GB en BDD, de los cuales 80 % son tablas ballast jamás limpiadas. Auditamos, cartografiamos, definimos una política de retención — y automatizamos. Sin romper la tienda. - Página: - Idioma: es - Publicado el: 2026-06-14 - Actualizado el: 2026-08-06 - Otros idiomas: [fr](https://www.datafirefly.com/2026/06/14/base-prestashop-tables-ballast-nettoyage-retention-2026/index.md), [en](https://www.datafirefly.com/en/2026/06/14/prestashop-database-ballast-tables-cleanup-retention-2026/index.md), [de](https://www.datafirefly.com/de/2026/06/14/prestashop-datenbank-ballast-tabellen-bereinigung-retention-2026/index.md), [it](https://www.datafirefly.com/it/2026/06/14/database-prestashop-tabelle-zavorra-pulizia-retention-2026/index.md), [pl](https://www.datafirefly.com/pl/2026/06/14/baza-prestashop-tabele-balastowe-czyszczenie-retencja-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/06/14/prestashop-database-ballasttabellen-opschonen-retentie-2026/index.md), [pt](https://www.datafirefly.com/pt/2026/06/14/base-prestashop-tabelas-lastro-limpeza-retencao-2026/index.md) - Índice: 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_statssearch` recibe de 300 a 800 líneas por día (cada búsqueda interna, incluso vacía). - `ps_connections` y `ps_connections_page` registran cada visita y cada página vista. Cuente de 5 000 a 15 000 líneas por día. - `ps_guest` crea un registro para cada visitante no autenticado. - `ps_cart` guarda todos los carritos — abandonados incluidos — para siempre. En algunas tiendas, encontramos un 90 % de carritos vacíos que datan de 2018. - `ps_log` captura 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: 1. `ps_statssearch` — 1,8 GB 2. `ps_connections_page` — 1,2 GB 3. `ps_pagenotfound` — 800 MB 4. `ps_connections` — 600 MB 5. `ps_log` — 400 MB 6. `ps_cart` — 350 MB 7. `ps_guest` — 300 MB 8. `ps_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**: 1. **Cron diario** que ejecuta la política de retención de cada tabla. 2. **Token de seguridad** para que el cron no sea desencadenable desde el exterior. 3. **Logs de ejecución** para seguir lo que se ha suprimido. 4. **Notificación** en caso de fallo o anomalía (volumen anormal de supresión). 5. **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 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 para el resto del cuadro, y la si prepara una migración: aligerar la BDD antes de la migración puede dividir por 5 el tiempo de báscula. Para pasar a la acción: [nuestra selección de módulos para el mantenimiento, las copias de seguridad y la fiabilidad](https://www.datafirefly.com/es/solutions/prestashop/mantenimiento-copias-seguridad/) y [la dedicada a acelerar su tienda](https://www.datafirefly.com/es/solutions/prestashop/rendimiento-velocidad/).