Limpiar la base de datos de PrestaShop: la guía SQL

Por qué una base hinchada sale cara

La base de datos de una tienda PrestaShop activa crece sin parar, y la mayor parte de ese volumen no tiene ningún valor de negocio. Las consecuencias se notan pronto: back-office que va lento, copias de seguridad que superan la cuota del alojamiento, restauraciones que tardan horas justo el día que hay que correr y exportaciones imposibles desde la interfaz de administración de la base.

La limpieza es una de las intervenciones con mejor relación entre resultado y esfuerzo. Eso sí, hay que saber qué se borra.

Identificar lo que pesa

Antes de nada, mida. Esta consulta ordena sus tablas por tamaño:

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS taille_mo,
       table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 25;

En la gran mayoría de los casos, la clasificación la dominan siempre los mismos culpables:

• ps_connections, ps_connections_source, ps_connections_page, ps_guest: el seguimiento de navegación de los visitantes;
• ps_page_viewed, ps_statssearch: las estadísticas nativas;
• ps_search_index y ps_search_word: el índice del buscador interno;
• ps_cart y ps_cart_product: los carritos, la inmensa mayoría de los cuales nunca llegó a convertirse en pedido;
• ps_log, ps_mail, ps_customer_thread: registros, historiales de correo y mensajes, a menudo llenos de spam.

Antes de borrar nada

Haga una copia de seguridad completa y compruebe que se restaura. Una purga es irreversible.

Trabaje primero con SELECT COUNT(*). Para cada borrado que se plantee, cuente antes las filas afectadas. Un DELETE lanzado con una condición mal escrita no tiene marcha atrás.

Ponga la tienda en modo mantenimiento para las purgas grandes, y evitará bloqueos sobre tablas que se están escribiendo.

Borre por lotes. Un DELETE sobre millones de filas puede saturar el registro de transacciones. Añada una cláusula LIMIT 50000 y repita.

Las purgas seguras

Las estadísticas de navegación. Solo tienen valor si de verdad usa las estadísticas nativas de PrestaShop, algo poco frecuente cuando ya hay una herramienta de analítica externa.

DELETE FROM ps_connections_page WHERE id_connections IN (
  SELECT id_connections FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
) LIMIT 50000;

DELETE FROM ps_connections_source WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH) LIMIT 50000;
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH) LIMIT 50000;

Respete este orden: primero las tablas hijas, después la tabla padre.

Los carritos sin pedido. Cuente antes de borrar:

SELECT COUNT(*) FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_order IS NULL AND c.date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);

Después borre las líneas de carrito asociadas antes que los carritos en sí. Atención: si trabaja con recordatorios de carrito abandonado, deje una ventana más amplia, seis meses como mínimo.

Los registros de la aplicación.

DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 50000;

El historial de correos. La tabla ps_mail solo sirve para consultar lo que se ha enviado. Con un año de retención va sobrado.

Lo que nunca hay que borrar

Los pedidos, las facturas y las rectificativas. Existe una obligación legal de conservación. Una tienda a la que se le ha purgado ps_orders para ganar espacio no se recupera.

Los clientes vinculados a un pedido. Aunque estén «inactivos». Borrarlos rompe el historial y las facturas.

Las tablas de estadísticas, si algún módulo depende de ellas. Ciertos módulos de atribución o de cuadro de mando leen ps_connections. Compruébelo antes o dejará sus informes vacíos.

Las tablas de configuración, sea cual sea su tamaño aparente.

Reindexar y reorganizar

Después de una purga, el espacio no se devuelve mientras las tablas no se reorganicen:

OPTIMIZE TABLE ps_connections, ps_connections_page, ps_cart, ps_log;

Regenere después el índice del buscador desde Parámetros de la tienda > Buscar > Reindexar toda la base de datos. En un catálogo grande, la interfaz supera el tiempo de ejecución permitido: use entonces la URL de tarea programada específica o procese por lotes.

Compruebe por último que no queda ninguna tabla en MyISAM tras antiguas migraciones:

SELECT table_name, engine FROM information_schema.TABLES
WHERE table_schema = DATABASE() AND engine <> 'InnoDB';

InnoDB gestiona los bloqueos a nivel de fila y no de tabla: la conversión elimina bloqueos invisibles pero muy reales en una tienda con actividad.

Convertirlo en rutina

Una limpieza anual no sirve de mucho: seis meses después la base vuelve a estar saturada. Implante una purga automática mensual sobre las tablas de estadísticas y de registros, con una retención decidida de una vez por todas.

Si su back-office sigue lento después de la limpieza, el problema está en otra parte: lea nuestro artículo sobre cómo acelerar una tienda PrestaShop.

Audite su base de datos

Medimos, purgamos e implantamos la rutina de limpieza, sin tocar jamás los datos contables. Consulte nuestra oferta de mantenimiento de PrestaShop.