Votre base de données PrestaShop grossit sans cesse : quelles tables vider et lesquelles garder

La sauvegarde de la base de données prend de plus en plus de temps, l'hébergeur vous prévient que vous approchez de la limite d'espace et un écran du back-office est lent. Vous regardez ce qui prend autant de place et découvrez que ce ne sont ni les produits ni les commandes : ce sont des tables aux noms comme connections, guest ou log, avec des millions de lignes que personne n'a jamais regardées.

Voyons quelles tables grossissent toutes seules, à quoi elles servent et ce que l'on peut nettoyer sans rien perdre d'important.

D'abord, mesurez

Avant de supprimer quoi que ce soit, obtenez la liste des tables triées par taille. phpMyAdmin ou l'outil de base de données de votre hébergeur l'affiche directement ; vous pouvez aussi interroger information_schema.TABLES en filtrant sur le nom de votre base et en triant par DATA_LENGTH + INDEX_LENGTH. Presque toujours, quelques tables concentrent l'essentiel de l'espace.

Dans les exemples, j'utilise le préfixe ps_, celui par défaut ; le vôtre peut être différent.

Celles qui grossissent à chaque visite

ps_connections et ps_connections_source

Elles enregistrent chaque visite de la boutique et la provenance du visiteur. Elles sont utilisées par les statistiques internes de PrestaShop (visiteurs, sources de trafic). Avec le trafic des robots, elles grossissent très vite.

Peut-on les nettoyer ? Oui, les anciennes lignes, si vous n'utilisez pas les statistiques internes de visites ou si une période récente vous suffit. Vous perdrez l'historique des visites de ces modules de statistiques, pas des commandes ni des clients.

ps_guest

Un enregistrement par visiteur identifié par un cookie, avec des données techniques du navigateur. Elle est liée aux connexions et aux paniers.

Peut-on la nettoyer ? Avec prudence : uniquement les visiteurs qui ne sont associés à aucun client ni à aucun panier ayant une commande. Supprimer les visiteurs sans discernement laisse des références cassées.

ps_pagenotfound, ps_statssearch et similaires

Pages introuvables et recherches du moteur interne, si vous avez activé les modules de statistiques correspondants. Elles sont utiles pour repérer les liens cassés et comprendre ce que cherchent vos clients, mais les lignes vieilles de plusieurs années le sont rarement.

Peut-on les nettoyer ? Oui, les anciennes. Si cela vous intéresse, exportez d'abord un résumé des recherches les plus fréquentes.

Les paniers

ps_cart et ps_cart_product conservent tous les paniers créés, y compris ceux qui n'ont jamais abouti à une commande. Dans une boutique qui existe depuis des années, il y en a des centaines de milliers.

• On ne touche jamais aux paniers ayant une commande. La commande pointe vers son panier, et de nombreux écrans, factures et modules en ont besoin.
• Pas davantage aux paniers récents sans commande : ce sont ceux des clients qui achètent en ce moment ou qui peuvent revenir, et ceux qu'utilisent les modules de relance des paniers abandonnés.
• Les paniers très anciens sans commande peuvent être supprimés, avec leurs lignes. Vérifiez d'abord qu'aucun module ne les utilise comme référence (règles panier associées, paniers enregistrés, devis).

Les journaux

ps_log

C'est le journal que vous voyez dans Paramètres avancés → Logs. Le cœur et les modules l'alimentent. Un module qui écrit un message à chaque visite peut le remplir en quelques semaines.

Peut-on le nettoyer ? Oui, le back-office propose une option pour le vider. Mais avant, regardez ce qui le remplit : si un message se répète des milliers de fois, il y a quelque chose à corriger, et vider la table ne fait que masquer le symptôme.

ps_mail

Le journal des e-mails envoyés, si vous avez activé leur enregistrement. Utile pour vérifier si un e-mail est bien parti, mais il contient des adresses de clients.

Peut-on le nettoyer ? Oui, et il est conseillé de le faire avec une durée de conservation définie. Conserver indéfiniment quels e-mails ont été envoyés à qui n'apporte rien et constitue une donnée personnelle de plus.

Tables des modules

Beaucoup de modules ont leurs propres journaux : appels d'API, synchronisations, alertes. Certains les purgent d'eux-mêmes, d'autres non. Examinez les grosses tables portant un préfixe de module et la configuration de chacun avant de supprimer à la main.

Ce à quoi on ne touche pas

Il vaut mieux ne pas toucher non plus :

• Aux clients et adresses, sauf dans le cadre d'une procédure d'effacement des données à la demande de la personne concernée, qui doit respecter ce que vous êtes légalement tenu de conserver.
• Aux prix spécifiques et règles panier expirés, sans vérifier d'abord si l'un d'eux sert de modèle ou si un module en dépend.
• Aux tables de configuration contenant des valeurs que vous ne reconnaissez pas : elles appartiennent souvent à des modules désinstallés, mais parfois à des modules actifs aux noms peu explicites.

Si le problème, ce sont les commandes

Parfois, la grosse table est celle des commandes, et c'est logique : une boutique active depuis des années en accumule beaucoup. Il ne s'agit pas alors de supprimer, mais d'archiver : sortir les anciennes commandes des tables actives pour que le back-office travaille avec moins de lignes, tout en les conservant complètes et récupérables.

Comment faire le nettoyage

1. Sauvegarde complète de la base de données, vérifiée.
2. Testez sur une copie de la boutique les requêtes de nettoyage et vérifiez que tout fonctionne encore : commandes, paniers des clients, statistiques.
3. Supprimez par lots, et non des millions de lignes en une seule requête, ce qui peut verrouiller la table et la boutique.
4. Optimisez les tables après une suppression importante, pour récupérer l'espace disque.
5. Corrigez la cause : désactivez les statistiques que vous n'utilisez pas, freinez les robots qui génèrent des milliers de connexions, réparez le module qui remplit le journal.
6. Planifiez le nettoyage pour ne pas avoir à refaire un grand ménage dans quelques années.

Comment le résoudre dans PrestaShop

RKR Order Archive sort des tables actives les commandes plus anciennes que le nombre de jours que vous fixez (180 par défaut), dans les états que vous choisissez, et les conserve complètes dans des tables d'archive : lignes, historique, factures, paiements, retours, avoirs, panier et messages. Il dispose d'un mode simulation pour voir combien de commandes et de lignes il déplacerait sans rien toucher, d'une tâche cron avec jeton, d'un rapport par e-mail, d'une restauration exacte avec le même numéro de commande et d'une suppression définitive bloquée par défaut. Il n'archive pas la commande portant le dernier numéro de facture, de bon de livraison ou de commande, pour que PrestaShop ne répète pas la numérotation. Pour les autres tables (connexions, visiteurs, paniers, journaux), avec un forfait d'heures de support Rekire, nous mesurons votre base de données, préparons le nettoyage sur une copie et le laissons planifié.