Tu base de datos de PrestaShop crece sin parar: qué tablas puedes vaciar y cuáles no
Una base de datos que ocupa gigas no siempre es culpa de los pedidos. Hay tablas que crecen con cada visita y que casi nadie consulta. Te contamos cuáles son, cuáles se pueden vaciar con seguridad y cuáles no deberías tocar nunca.
La copia de seguridad de la base de datos tarda cada vez más, el hosting avisa de que te acercas al límite de espacio y alguna pantalla del back-office va lenta. Miras qué ocupa tanto y descubres que no son los productos ni los pedidos: son tablas con nombres como connections, guest o log, con millones de filas que nadie ha mirado nunca.
Vamos a ver qué tablas crecen solas, para qué sirven y qué se puede limpiar sin perder nada importante.
Primero, mide
Antes de borrar nada, saca la lista de tablas ordenadas por tamaño. Desde phpMyAdmin o la herramienta de base de datos de tu hosting se ve directamente; también con una consulta a information_schema.TABLES filtrando por el nombre de tu base de datos y ordenando por DATA_LENGTH + INDEX_LENGTH. Casi siempre, unas pocas tablas concentran la mayor parte del espacio.
En los ejemplos uso el prefijo ps_, que es el de serie; el tuyo puede ser otro.
Las que crecen con cada visita
ps_connections y ps_connections_source
Registran cada visita a la tienda y de dónde venía el visitante. Las usan las estadísticas internas de PrestaShop (visitantes, orígenes de tráfico). Con tráfico de bots, crecen muy deprisa.
¿Se pueden limpiar? Sí, las filas antiguas, si no usas las estadísticas internas de visitas o te basta con un periodo reciente. Perderás el histórico de visitas de esos módulos de estadísticas, no pedidos ni clientes.
ps_guest
Un registro por cada visitante identificado con una cookie, con datos técnicos del navegador. Se relaciona con las conexiones y con los carritos.
¿Se pueden limpiar? Con cuidado: solo los invitados que no están asociados a ningún cliente ni a ningún carrito con pedido. Borrar invitados a lo bruto deja referencias rotas.
ps_pagenotfound, ps_statssearch y similares
Páginas no encontradas y búsquedas del buscador interno, si tienes activos los módulos de estadísticas correspondientes. Son útiles para detectar enlaces rotos y entender qué buscan tus clientes, pero las filas de hace años rara vez lo son.
¿Se pueden limpiar? Sí, las antiguas. Antes, si te interesa, exporta un resumen de las búsquedas más frecuentes.
Los carritos
ps_cart y ps_cart_product guardan todos los carritos creados, también los que nunca acabaron en pedido. En una tienda con años de vida son cientos de miles.
- Los carritos con pedido no se tocan nunca. El pedido apunta a su carrito, y muchas pantallas, facturas y módulos lo necesitan.
- Los carritos sin pedido recientes tampoco: son los de clientes que están comprando ahora o que pueden volver, y los que usan los módulos de recuperación de carritos abandonados.
- Los carritos sin pedido muy antiguos se pueden eliminar, junto con sus líneas. Revisa antes que ningún módulo los use como referencia (reglas de carrito asociadas, carritos guardados, presupuestos).
Los registros
ps_log
Es el registro que ves en Parámetros avanzados → Registros. Lo alimentan el núcleo y los módulos. Un módulo que escribe un mensaje en cada visita puede llenarlo en semanas.
¿Se puede limpiar? Sí, el back-office tiene opción para vaciarlo. Pero antes mira qué lo llena: si un mensaje se repite miles de veces, hay algo que arreglar, y vaciar la tabla solo esconde el síntoma.
ps_mail
El registro de correos enviados, si tienes activado guardar los correos. Útil para comprobar si un correo salió, pero contiene direcciones de clientes.
¿Se puede limpiar? Sí, y conviene hacerlo con un periodo de conservación definido. Guardar indefinidamente qué correos se mandaron a quién no aporta nada y es un dato personal más.
Tablas de módulos
Muchos módulos tienen sus propios registros: llamadas a APIs, sincronizaciones, avisos. Algunos los purgan solos y otros no. Revisa las tablas grandes con prefijo de módulo y la configuración de cada uno antes de borrar a mano.
Lo que no se toca
orders, order_detail, order_history, order_invoice, order_payment…) están relacionadas entre sí y con clientes, direcciones y carritos, y las facturas tienen obligaciones legales de conservación. Un pedido borrado con una consulta deja restos en otras tablas, rompe la numeración que PrestaShop calcula a partir del último y descuadra la contabilidad.Tampoco conviene tocar:
- Clientes y direcciones, salvo por un procedimiento de supresión de datos a petición del interesado, que tiene que respetar lo que debas conservar por obligación legal.
- Precios específicos y reglas de carrito caducadas sin revisar antes si alguna se usa como plantilla o si un módulo depende de ellas.
- Tablas de configuración con valores que no reconoces: suelen ser de módulos desinstalados, pero a veces son de módulos activos con nombres poco claros.
Si el problema son los pedidos
A veces la tabla grande es la de pedidos, y es lógico: una tienda con años de actividad acumula muchos. Ahí no se trata de borrar sino de archivar: sacar los pedidos antiguos de las tablas activas para que el back-office trabaje con menos filas, conservándolos completos y recuperables.
Cómo hacer la limpieza
- Copia completa de la base de datos, comprobada.
- Prueba en una copia de la tienda las consultas de limpieza y revisa que todo sigue funcionando: pedidos, carritos de clientes, estadísticas.
- Borra por lotes, no millones de filas en una sola consulta, que puede bloquear la tabla y la tienda.
- Optimiza las tablas después de borrar mucho, para recuperar el espacio en disco.
- Corrige la causa: desactiva estadísticas que no usas, frena a los bots que generan miles de conexiones, arregla el módulo que llena el registro.
- Programa la limpieza para que no vuelva a hacer falta una gran limpieza dentro de unos años.
Cómo resolverlo en PrestaShop
RKR Order Archive saca de las tablas activas los pedidos más antiguos que el número de días que fijes (180 por defecto), en los estados que elijas, y los guarda completos en tablas de archivo: líneas, historial, facturas, pagos, devoluciones, abonos, carrito y mensajes. Tiene modo simulación para ver cuántos pedidos y filas movería sin tocar nada, cron con token, informe por correo, restauración exacta con el mismo número de pedido y borrado definitivo bloqueado por defecto. No archiva el pedido con el último número de factura, albarán o pedido para que PrestaShop no repita la numeración. Para el resto de tablas (conexiones, invitados, carritos, registros), con un bono de horas de soporte de Rekire medimos tu base de datos, preparamos la limpieza en una copia y la dejamos programada.