Nettoyer la base de données PrestaShop

Votre boutique ralentit. Le back-office met 8 secondes à charger. Les sauvegardes plantent en timeout. Et un matin, c’est l’erreur 500. Ou pire, votre hébergeur suspend le site parce que le quota disque est dépassé.

Le coupable ? Presque toujours le même. Une base de données qui a triplé de volume en deux ans. Sans que personne ne s’en rende compte.

Chez CYBERIAL, c’est la cause de ralentissement qu’on diagnostique le plus souvent quand on reprend une boutique PrestaShop. Et pourtant, c’est la plus simple à corriger ! Encore faut-il savoir quoi nettoyer, quoi ne surtout pas toucher, et comment faire pour que le problème ne revienne pas tous les six mois.

C’est exactement ce qu’on va voir dans cet article. Pas une liste de requêtes SQL à copier-coller (ça, il y en a partout). Un vrai guide pour nettoyer la base de données PrestaShop : pourquoi votre base grossit, quelles tables vous pouvez vider sans perdre de commandes, lesquelles sont piégées, et comment automatiser le nettoyage pour ne plus y penser.

Pourquoi la base de données PrestaShop grossit ?

PrestaShop enregistre tout. Chaque visite sur votre site crée une ligne dans ps_connections. Chaque page vue : une ligne dans ps_connections_page. Chaque visiteur non connecté : une ligne dans ps_guest. Chaque source de trafic : ps_connections_source. Chaque erreur 404 : ps_pagenotfound. Chaque recherche interne : ps_statssearch. Chaque email envoyé : ps_mail. Chaque action dans le back-office : ps_log.

Et le cœur du CMS ne nettoie jamais, ainsi votre boutique PrestaShop est lente.

Faisons le calcul. Votre boutique reçoit 500 visites par jour, ce qui est modeste pour un e-commerce actif. Chaque visite alimente 4 à 5 tables. Sur un an, ça fait environ 900 000 lignes rien que pour le suivi des connexions. Sur deux ans sans nettoyage, vous dépassez facilement les 2 millions de lignes, et votre base passe de 200 Mo à 2 ou 3 Go.

Ce qui est pervers, c’est que ça ne se voit pas au quotidien. Le ralentissement est progressif : 1 seconde de plus chaque trimestre. Vous vous habituez. Jusqu’au jour où une sauvegarde qui prenait 2 minutes en met maintenant 20. Ou que votre hébergeur mutualisé vous coupe parce que vous avez explosé votre quota MySQL.

Au passage : le module officiel « PrestaShop Cleaner » (aussi appelé « Database Cleaner ») n’est plus mis à jour par PrestaShop depuis février 2021. Abandonné, pas remplacé. Si vous le cherchez encore sur Addons, vous ne le trouverez plus. Les marchands sont livrés à eux-mêmes, et la plupart ne le savent même pas.

Et c’est cette même base de données gonflée qui est derrière les erreurs 500 quand MySQL timeout, les pages blanches quand le disque est plein, et les ralentissements progressifs que tout le monde met sur le dos de l’hébergeur !

Mon conseil : avant d’acheter un serveur plus cher, vérifiez la taille de votre base de données. Ouvrez phpMyAdmin, sélectionnez votre base, triez les tables par taille. Si ps_connections ou ps_guest pèsent plus de 100 Mo, vous tenez votre coupable.

Quelles tables vider dans la base de données PrestaShop ?

C’est LA question que tout le monde se pose, et à laquelle on trouve rarement une réponse complète. Les articles que vous trouvez en ligne vous donnent une liste de TRUNCATE à exécuter. Mais ils ne vous disent pas que certaines tables sont piégées, et qu’un TRUNCATE brutal peut casser des fonctionnalités de votre boutique.

On va faire autrement. Voici le classement qu’on utilise en interne chez CYBERIAL. Trois catégories, trois couleurs. Pas d’ambiguïté pour vous aider à nettoyer votre base de données PrestaShop.

Les tables qu’on peut vider sans perdre de commandes (TRUNCATE direct)

Ces tables ne contiennent que des données de suivi et de statistiques. Elles ne stockent ni vos commandes, ni vos clients, ni votre catalogue : les vider ne fait perdre que des historiques, comme le bloc « Sources » des commandes ou les « Dernières connexions » des fiches clients. Si vous utilisez Google Analytics ou Matomo pour vos statistiques (et vous devriez), ces données ne vous servent presque à rien.

Table	Ce qu’elle contient	Taille typique après 2 ans
ps_connections	Une ligne par visite	500 Mo à 2 Go
ps_connections_page	Pages vues par visite	500 Mo à 3 Go
ps_connections_source	Source de chaque visite	100 à 500 Mo
ps_guest	Sessions visiteurs anonymes	200 Mo à 1 Go
ps_pagenotfound	Chaque erreur 404 (les bots en génèrent des tonnes)	50 à 500 Mo
ps_statssearch	Recherches internes des visiteurs	10 à 100 Mo
ps_log	Logs système du back-office	50 à 300 Mo
ps_mail	Historique de chaque email envoyé	20 à 200 Mo

Action : ouvrez phpMyAdmin, sélectionnez ces tables, et cliquez sur « Vider » (TRUNCATE). Le vidage lui-même prend quelques secondes. Faites toujours une sauvegarde avant. Trois réserves : videz ps_guest et les trois tables ps_connections ensemble, sinon les numéros repartent de 1 et se mélangent ; ne touchez pas à ps_log si vous soupçonnez un piratage ; et pour garder les derniers mois, utilisez plutôt les requêtes de l’index des tables.

Le résultat surprend. Sur une boutique jamais nettoyée, ces tables de statistiques sont souvent les plus lourdes de la base : c’est là que vous récupérez le plus de place.

Les tables qu’on peut vider avec précaution (DELETE conditionnel)

Ces tables contiennent des données qui peuvent être liées à des fonctionnalités actives. Un TRUNCATE brutal peut casser des choses. Il faut un DELETE ciblé, pas un nettoyage aveugle.

ps_cart et ps_cart_product : les paniers

Attention : PrestaShop garde tous les paniers, y compris ceux qui n’ont jamais abouti à une commande. Sur une boutique active, ça se compte en centaines de milliers de lignes. Mais on ne peut pas tout supprimer : les paniers liés à des commandes doivent rester (ils sont référencés dans ps_orders), et les paniers récents de visiteurs en cours de navigation aussi.

La règle : supprimer uniquement les paniers de plus de 30 jours qui ne sont liés à aucune commande. En SQL, ça donne :

DELETE FROM ps_cart WHERE id_cart NOT IN (SELECT id_cart FROM ps_orders) AND date_upd < DATE_SUB(NOW(), INTERVAL 30 DAY);

Cette requête laisse les lignes de ps_cart_product des paniers supprimés. La version complète, qui les nettoie aussi, est dans l’index des tables.

ps_guest (en mode ciblé)

J’ai classé ps_guest en vert pour le TRUNCATE, avec une nuance : chaque panier garde le numéro de son visiteur (colonne id_guest de ps_cart), et les fiches clients s’en servent pour afficher leurs dernières connexions.

Un TRUNCATE ne vide aucun panier : les paniers sont dans ps_cart, pas ici. Mais les fiches clients perdent leurs « Dernières connexions » et les commandes leur bloc « Sources ». Et le TRUNCATE fait repartir les numéros de visiteurs à 1 : si ps_connections n’est pas vidée en même temps, un nouveau visiteur hérite des visites d’un ancien, adresse IP comprise.

Si votre boutique a beaucoup de trafic, préférez le DELETE ciblé donné dans l’index des tables : il ne supprime que les visiteurs qui n’ont plus ni visite ni panier.

ps_specific_price : les prix spécifiques

Ce sont les promotions, prix par client, par groupe, etc. Vous pouvez supprimer les prix expirés :

DELETE FROM ps_specific_price WHERE `to` != '0000-00-00 00:00:00' AND `to` < NOW();

Les tables à ne jamais toucher

• ps_orders, ps_order_detail : vos commandes.
• ps_customer, ps_address : vos clients.
• ps_product, ps_product_attribute, ps_category : votre catalogue.
• ps_configuration : la config de votre boutique.
• ps_layered_filter : vos modèles de filtres de la navigation à facettes. Ne la confondez pas avec sa voisine ps_layered_filter_block, qui n’est qu’un cache.

On voit souvent passer dans les forums la question de vider ps_layered_filter_block, parce que cette table peut peser lourd. D’après le code du module, la vider ne casse rien : le module le fait lui-même chaque fois qu’un produit est enregistré. La méthode, et ce qu’il faut regarder si elle se remplit trop vite, sont dans l’index des tables.

Index des tables PrestaShop qui grossissent

Vous avez repéré une grosse table dans phpMyAdmin ? Cherchez-la ci-dessous. Chaque entrée suit le même plan, du contenu de la table jusqu’au moment où il faut s’arrêter. On a vérifié chaque point dans le code de PrestaShop 1.6.1, 1.7.8, 8.2 et 9, et dans celui des modules concernés.

• ps_layered_filter_block : le cache des filtres
• ps_layered_price_index : l’index des prix des filtres
• ps_connections : les visites
• ps_connections_source : la provenance des visites
• ps_connections_page : les pages vues par visite
• ps_cart et ps_cart_product : les paniers abandonnés
• ps_guest : les visiteurs
• ps_pagenotfound : les erreurs 404
• ps_statssearch : les recherches internes
• ps_log : le journal du back-office
• ps_mail : l’historique des e-mails
• ps_cart_rule_combination : les combinaisons de codes promo (section suivante)

Les noms utilisent le préfixe par défaut ps_. Le vôtre peut être différent : c’est le début du nom de toutes vos tables dans phpMyAdmin (il est aussi écrit dans app/config/parameters.php en 1.7, 8 et 9, et dans config/settings.inc.php en 1.6). Dans les requêtes, remplacez PREFIX_ par votre préfixe, par exemple ps_.

Avant toute requête :

• faites une sauvegarde complète de la base, de préférence avec l’outil de votre hébergeur : sur une grosse base, l’export de phpMyAdmin peut s’arrêter avant la fin ;
• exportez aussi la table concernée : onglet « Exporter », méthode « Personnalisée », « données » seules, puis sous « Au lieu d’instructions INSERT, utiliser : », cochez « Instructions INSERT IGNORE ». C’est votre retour arrière : réimporté, ce fichier remet les lignes supprimées sans toucher à celles arrivées depuis. Après un vidage complet (« Vider » dans phpMyAdmin, « Tout supprimer » dans le back-office), la numérotation repart de 1 : pour annuler, passez la boutique en maintenance et réimportez aussitôt, avant que de nouvelles lignes arrivent ;
• une fois toutes les tranches passées, lancez « Optimiser la table » (onglet « Opérations »), hors des heures de vente : un DELETE ne rend pas tout de suite la place sur le disque, et MySQL recopie la table : il faut autant d’espace libre qu’elle en occupe. Le message « Table does not support optimize, doing recreate + analyze instead » est normal ;
• les requêtes sur une seule table finissent par LIMIT 50000 : relancez-les jusqu’à ce qu’elles ne suppriment plus aucune ligne. Celles qui portent sur plusieurs tables n’acceptent pas de LIMIT : pour les paniers et les visiteurs, leur entrée explique comment les découper.

ps_layered_filter_block

Ce qu’elle contient. Le cache des filtres du module « Navigation à facettes » (ps_facetedsearch 3.0 et plus, en 1.7, 8 et 9). Une ligne par combinaison de filtres affichée sur une catégorie, une marque ou un fournisseur.

Pourquoi elle grossit. Chaque combinaison inédite ajoute une ligne. Le module la vide à chaque enregistrement d’un produit, à l’ajout ou au retrait d’une catégorie et à chaque changement de réglage : elle gonfle quand le catalogue bouge peu et que des robots balaient les filtres. Sur les boutiques que nous hébergeons, on relève souvent des milliers de requêtes de filtres par jour, venues de robots et sans aucune commande (été 2026).

Ce qu’on peut vider. Tout : c’est un cache, recalculé à la visite suivante. Ne supprimez pas la table et ne la confondez pas avec ps_layered_filter (vos modèles de filtres).

Comment. Modules > Gestionnaire de modules > « Navigation à facettes » > Configurer, bloc « Index et caches » : « Vider le cache ». Sinon, après un export :

TRUNCATE TABLE PREFIX_layered_filter_block;

Pour annuler : rien à faire. Arrêtez-vous si la table se remplit de nouveau en quelques heures : ce sont les robots qu’il faut traiter.

ps_layered_price_index

Ce qu’elle contient. Le prix le plus bas et le plus haut de chaque produit, par devise, boutique et pays, pour le filtre et le tri par prix de la « Navigation à facettes » (sans colonne pays en 1.6).

Pourquoi elle grossit. Elle suit le catalogue, pas le trafic. Depuis la version 5.1.0 du module (septembre 2026, PrestaShop 8.2 et plus), chaque produit est indexé pour chaque pays actif. Les lignes des produits supprimés restent, même après « Reconstruire l’index intégralement ».

Ce qu’on peut vider. Les lignes des produits qui n’existent plus. Ne la videz jamais entièrement sans la reconstruire : le tri par prix ne renverrait plus aucun produit.

Comment. Désactivez les pays où vous ne vendez pas, sauf si un client y a une adresse (International > Zones géographiques > Pays) : ce client verrait le tri par prix vide. Puis « Reconstruire l’index intégralement » (bloc « Index et caches »). Pour les produits supprimés, pas de bouton ; après un export :

DELETE i FROM PREFIX_layered_price_index i
LEFT JOIN PREFIX_product p ON p.id_product = i.id_product
WHERE p.id_product IS NULL;

Pour annuler : réimportez l’export, puis « Indexer tous les prix manquants ». Arrêtez-vous si une catégorie triée par prix s’affiche vide : relancez la reconstruction.

ps_connections

Ce qu’elle contient. Une ligne par visite : visiteur, date, adresse IP, site d’origine. C’est le module « Récupération des données statistiques » (statsdata), installé par défaut, qui l’alimente.

Pourquoi elle grossit. Une nouvelle visite commence après 30 minutes d’inactivité. Jusqu’à la 9.1, la liste des robots écartés reconnaît Googlebot, mais ni Bingbot, ni les robots d’IA, ni les outils SEO : ils comptent comme des visites. La 9.2 ajoute notamment Bingbot, GPTBot, ClaudeBot et AhrefsBot, mais pas les robots non déclarés. Sur les boutiques qu’on reprend, ps_connections, ps_connections_source et ps_guest pèsent ensemble jusqu’à plus d’un Go. Sur les bases que nous avons mesurées, la sauvegarde de nuit passait près d’une minute sur chacune des deux plus grosses avant nettoyage (relevé de juillet 2026).

Ce qu’on peut vider. Les visites de plus de trois mois, si Google Analytics ou Matomo mesure le trafic. Vous perdez l’historique des Statistiques, les « Dernières connexions » des clients et le bloc « Sources » des commandes.

Comment. Aucun bouton. Après un export, relancez jusqu’à 0 ligne supprimée, puis passez aux deux tables suivantes :

DELETE FROM PREFIX_connections
WHERE date_add < NOW() - INTERVAL 90 DAY
LIMIT 50000;

Pour annuler : réimportez l’export. Arrêtez-vous si la table regrossit aussi vite : coupez la source.

ps_connections_source

Ce qu’elle contient. Pour chaque visite, la page d’où vient le visiteur, l’adresse demandée et les mots-clés lisibles dans l’adresse d’origine. Même module statsdata. PrestaShop l’affiche dans le bloc « Sources » de la fiche commande.

Pourquoi elle grossit. Une ligne s’ajoute pour chaque page vue qui arrive d’un autre site. Un lien interne n’en crée pas. En 8 et 9, une page vue sans site d’origine en ajoute une aussi. Or presque tous les robots arrivent sans site d’origine : sur ces versions, chacune de leurs pages ajoute une ligne. En 1.6 et 1.7, ces pages ne comptent que si l’option « Enregistrer le trafic direct » est sur Oui (elle est sur Non à l’installation).

Ce qu’on peut vider. Tout ce qui est plus ancien que ce que vous gardez dans ps_connections. Rien ici ne sert aux commandes ni aux paiements.

Comment. Pas de bouton. Après un export, avec la même durée que pour les visites :

DELETE FROM PREFIX_connections_source
WHERE date_add < NOW() - INTERVAL 90 DAY
LIMIT 50000;

Pour annuler : réimportez l’export. Arrêtez-vous si cette table grossit plus vite que ps_connections : des robots enchaînent les pages, la purge n’y changera rien. Coupez la source.

ps_connections_page

Ce qu’elle contient. Les pages vues pendant chaque visite, avec l’heure d’arrivée et de départ. Elle ne se remplit que si l’option « Enregistrer les pages vues pour chaque client » du module statsdata est sur Oui. Elle est sur Non à l’installation.

Pourquoi elle grossit. Une ligne par page vue : c’est vite la plus lourde des tables de statistiques. PrestaShop prévoit un nettoyage automatique, mais son réglage est masqué dans le back-office (1.6 à 9.2) et reste sur « jamais ».

Ce qu’on peut vider. Toute la table si l’option est sur Non. Sinon, tout ce qui dépasse votre durée de conservation.

Comment. Passez l’option sur Non (configuration du module « Récupération des données statistiques »). Après un export, cliquez sur « Vider » dans phpMyAdmin. Si vous gardez l’option sur Oui, lancez plutôt cette requête chaque mois. N’activez pas le nettoyage masqué : il parcourt toute la table à chaque nouvelle visite.

DELETE FROM PREFIX_connections_page
WHERE time_start < NOW() - INTERVAL 90 DAY
LIMIT 50000;

Pour annuler : réimportez l’export. Arrêtez-vous si la table pèse plusieurs Go et que l’option est sur Non : ne la purgez pas par tranches, videz-la d’un coup.

ps_cart et ps_cart_product

Ce qu’elles contiennent. Chaque panier enregistré dès le premier article ajouté, et ses lignes produits. Le cœur les écrit et ne purge jamais les paniers sans commande.

À garder. Les paniers liés à une commande, et les récents : un paiement peut créer la commande après coup, et un client peut revenir. Supprimez uniquement les paniers sans commande de plus de 30 jours ; chez nous, on en garde 90.

Comment. Commandes > Paniers (Clients > Paniers en 1.6) : filtrez sur « Panier abandonné » (colonne « ID commande » jusqu’à la 8, « État » en 9) et sur la date, car PrestaShop appelle « abandonné » tout panier sans commande de plus de 24 h. Cochez, puis « Supprimer la sélection ». Au-delà de quelques centaines, après un export des trois tables :

DELETE c FROM PREFIX_cart c
LEFT JOIN PREFIX_orders o ON o.id_cart = c.id_cart
WHERE o.id_cart IS NULL
AND c.date_upd < NOW() - INTERVAL 90 DAY;

DELETE cp FROM PREFIX_cart_product cp
LEFT JOIN PREFIX_cart c ON c.id_cart = cp.id_cart
WHERE c.id_cart IS NULL;

DELETE cr FROM PREFIX_cart_cart_rule cr
LEFT JOIN PREFIX_cart c ON c.id_cart = cr.id_cart
WHERE c.id_cart IS NULL;

Si la première requête dépasse le délai, ajoutez AND c.id_cart < 100000 et augmentez ce nombre à chaque passage. Pour des produits personnalisables, passez par le back-office : lui seul efface les fichiers envoyés.

Pour annuler : réimportez les trois exports. Arrêtez-vous si un module de relance des paniers abandonnés est actif : vérifiez d’abord sur combien de jours il travaille.

ps_guest

Ce qu’elle contient. Une ligne par visiteur reconnu par son cookie : système, navigateur, langue, et le compte client s’il se connecte. C’est statsdata qui crée ces lignes, et qui y ajoute le compte à la connexion. Les paniers n’y sont pas (ils sont dans ps_cart), ni les commandes sans compte (dans ps_customer).

Pourquoi elle grossit. Un robot ne garde pas de cookie : chaque passage crée un nouveau visiteur, y compris Googlebot. Dans les bases que nous avons mesurées, on trouve presque toujours autant de lignes dans ps_guest que dans ps_connections (relevé de juillet 2026).

Ce qu’on peut vider. Les visiteurs qui n’ont plus ni visite ni panier. Faites-le après avoir nettoyé ps_connections et ps_cart.

Comment. Pas de bouton. Après un export, de préférence la nuit :

DELETE g FROM PREFIX_guest g
LEFT JOIN PREFIX_connections c ON c.id_guest = g.id_guest
LEFT JOIN PREFIX_cart ca ON ca.id_guest = g.id_guest
WHERE c.id_guest IS NULL AND ca.id_guest IS NULL;

Pour annuler : réimportez l’export. Sur un hébergement mutualisé, procédez d’emblée par tranches : ajoutez AND g.id_guest < 500000 à la fin, puis augmentez ce nombre à chaque passage. Arrêtez-vous si une tranche dépasse le délai de phpMyAdmin : la requête peut continuer sur le serveur. Attendez avant de relancer, avec une tranche plus petite.

ps_pagenotfound

Ce qu’elle contient. Chaque erreur 404 servie par PrestaShop : adresse demandée, page d’origine, date. Le module « Pages introuvables » (pagesnotfound) l’écrit.

Pourquoi elle grossit. Les robots testent des adresses qui n’existent pas sur une boutique (/wp-login.php, fichiers .env, anciennes URL) : chaque essai qui atteint PrestaShop ajoute une ligne.

Ce qu’on peut vider. Tout, c’est un rapport. Avant, parcourez la liste : une 404 qui vient de vos propres pages est un lien cassé à corriger ou à rediriger.

Comment. Statistiques > « Pages introuvables », de la 1.6 à la 9 : bouton « Vider toutes les mentions « pages introuvables » », ou seulement celles de la période choisie. En SQL, après un export :

DELETE FROM PREFIX_pagenotfound
WHERE date_add < NOW() - INTERVAL 90 DAY
LIMIT 50000;

Pour annuler : réimportez l’export. Arrêtez-vous si la liste est de nouveau longue quelques jours plus tard : bloquez ces robots en amont. Si vous suivez vos 404 dans Google Search Console, vous pouvez aussi désactiver le module.

ps_statssearch

Ce qu’elle contient. Chaque recherche faite sur la boutique : les mots tapés, le nombre de résultats, la date. Elle est remplie par le module « Recherches de la boutique » (statssearch).

Pourquoi elle grossit. Une ligne chaque fois qu’une page de résultats s’affiche, y compris les pages 2, 3 et suivantes et chaque changement de tri. La barre de recherche en ajoute aussi une à chaque série de suggestions affichée pendant la frappe : « cha », puis « chaus », puis « chaussure ».

À garder. C’est la liste de ce que vos clients cherchent, y compris ce qu’ils ne trouvent pas (0 résultat). Exportez-la avant de vider : Statistiques > « Recherches de la boutique », bouton d’export CSV.

Comment. Le module n’a pas de bouton pour vider. Après un export :

DELETE FROM PREFIX_statssearch
WHERE date_add < NOW() - INTERVAL 90 DAY
LIMIT 50000;

Pour annuler : réimportez l’export. Arrêtez-vous si elle pèse moins de quelques dizaines de Mo : le gain est nul, et l’historique des recherches vaut plus que la place.

ps_log

Ce qu’elle contient. Le journal de Paramètres avancés > Logs : erreurs (modules de paiement, envoi d’e-mails), ajouts, modifications et suppressions faits par vos employés, et, de la 1.6 à la 8, chaque « Connexion au back-office depuis » suivie de l’adresse IP. Le cœur et les modules y écrivent.

Pourquoi elle grossit. Un module qui journalise chaque appel, ou une erreur qui se répète des milliers de fois.

À garder. Si vous soupçonnez un piratage, ne videz rien : les connexions et les suppressions sont des preuves. Exportez d’abord, puis suivez notre guide pour une boutique PrestaShop piratée. Attaque en cours ? Appelez le 09 72 03 59 17.

Comment. Paramètres avancés > Logs : « Tout supprimer » (dans le menu d’actions de la liste en 1.7, 8 et 9). Pour garder les trois derniers mois, après un export :

DELETE FROM PREFIX_log
WHERE date_add < NOW() - INTERVAL 90 DAY
LIMIT 50000;

Pour annuler : réimportez l’export. Arrêtez-vous si la table reprend des milliers de lignes par jour : triez par message, trouvez celui qui se répète, et corrigez sa cause. La purge ne fait que le cacher.

ps_mail

Ce qu’elle contient. Une ligne par e-mail envoyé et par destinataire, copies comprises : adresse, modèle, objet, date. Le cœur l’écrit tant que l’option « Loguer les e-mails envoyés » est sur Oui, ce qui est le cas à l’installation. Elle prouve que PrestaShop a transmis l’e-mail, pas qu’il est arrivé.

Pourquoi elle grossit. Chaque commande déclenche plusieurs e-mails (confirmation, changements d’état), et rien n’est jamais purgé. Elle garde aussi sans limite les adresses de vos clients.

Ce qu’on peut vider. Les e-mails de plus de six mois. Gardez les récents : ils répondent au client qui dit n’avoir rien reçu.

Comment. Paramètres avancés > E-mail (« Email » en 1.6) : « Tout supprimer », ou l’option « Loguer les e-mails envoyés » sur Non pour arrêter l’historique. Pour garder six mois, après un export :

DELETE FROM PREFIX_mail
WHERE date_add < NOW() - INTERVAL 180 DAY
LIMIT 50000;

Pour annuler : réimportez l’export, ou remettez l’option sur Oui. Arrêtez-vous si vous cherchez un e-mail qui n’arrive pas : cette table ne vous le dira pas. Voyez plutôt pourquoi PrestaShop n’envoie pas vos e-mails.

Focus sur ps_cart_rule_combination

C’est la table dont aucun guide de nettoyage ne parle. Et c’est potentiellement la plus grosse de votre base.

Voici comment ça fonctionne. Quand vous créez un code promo dans PrestaShop et que vous le rendez « non cumulable » avec d’autres promotions, PrestaShop insère une ligne dans ps_cart_rule_combination pour chaque combinaison possible avec les autres règles. Si vous avez 100 règles de panier : 100 × 100 = 10 000 lignes. 1 000 règles : 1 000 × 1 000 = 1 million de lignes. C’est une croissance mathématique exponentielle facile à comprendre.

Un forum PrestaShop rapporte 167 millions de lignes. Et le pire ? C’est un bug de conception connu depuis 2011. Il n’a jamais été corrigé dans le cœur du logiciel.

Vous êtes particulièrement exposé si vous utilisez des modules marketing qui créent des règles de panier « à la volée » : parrainage, affiliation, codes promo automatiques par email. Ces modules peuvent générer des centaines de règles par semaine. Et chaque nouvelle règle multiplie les combinaisons.

Comment vérifier : dans phpMyAdmin, cherchez ps_cart_rule_combination et regardez sa taille. Si elle pèse plus de 100 Mo, vous avez un problème. Si elle pèse plus de 1 Go, c’est une urgence.

Comment nettoyer : commencez par supprimer les règles de panier expirées ou inutilisées (dans le back-office : Catalogue → Réductions → Règles panier). Chaque règle supprimée devrait aussi supprimer ses combinaisons. Si ça ne suffit pas (parce que les combinaisons orphelines restent), certains modules de nettoyage comme celui de Comonsoft gèrent spécifiquement cette table. Attention, nous ne l’avons pas testé sur PS 8 et 9.

Comment éviter le problème : quand vous créez un code promo, ne cochez pas « non cumulable » par défaut. Ne le faites que si c’est vraiment nécessaire. Et pensez à supprimer les règles de panier expirées régulièrement : PrestaShop ne le fait pas automatiquement.

Comment nettoyer la base de données PrestaShop ?

Méthode 1 : phpMyAdmin (pour ceux qui sont à l’aise)

C’est la méthode gratuite et directe.

1. Sauvegardez votre base : avec l’outil de sauvegarde de votre hébergeur, ou dans phpMyAdmin → votre base → Exporter → SQL → bouton « Exporter » (« Exécuter » sur les anciennes versions). Gardez le fichier précieusement.
2. Identifiez les tables volumineuses : cliquez sur le nom de votre base, puis triez les tables par la colonne « Taille ». Les coupables sautent aux yeux.
3. Nettoyez les tables vertes : cochez-les, puis, en bas de page, choisissez « Vider » dans la liste « Avec la sélection : », en respectant les trois réserves données plus haut.
4. Nettoyez les tables oranges : dans l’onglet SQL, collez les requêtes DELETE conditionnelles que j’ai données plus haut. Adaptez le préfixe si le vôtre n’est pas ps_.

Les requêtes elles-mêmes vont vite. Ce qui prend du temps, c’est le reste : la sauvegarde, l’export de chaque table, les passages par tranches sur une grosse base, puis « Optimiser la table » hors des heures de vente. Prévoyez une soirée tranquille. Vos sauvegardes, ensuite, seront nettement plus rapides.

Méthode 2 : un module de nettoyage (pour tout le monde)

Si le SQL vous fait peur (et c’est tout à fait normal pour un marchand), utilisez un module :

• mypresta.eu Database Optimization (gratuit) : le plus simple. Interface basique, mais il gère les 5 tables principales et ne supprime que les paniers non liés à une commande. Supporte PS 1.6 à 9.x.
• Comonsoft Optimisation BDD (payant, ~20 €) : déjà évoqué dans l’article, complet et pas cher. Gère ps_cart_rule_combination, permet de planifier un nettoyage automatique par cron. Compatible PS 8.x et 9.x.
• Mediacom87 Optimisation et nettoyage (payant, sur Addons) : gère le nettoyage et la restauration en cas d’erreur. Interface détaillée avec statistiques avant/après.
• PrestaToolbox (payant) : le plus avancé. Propose des « scénarios » de nettoyage (paniers, prix expirés, adresses orphelines, etc.) et l’automatisation par cron.

Mon avis : si vous ne faites le nettoyage qu’une fois et que vous êtes à l’aise avec phpMyAdmin, la méthode 1 suffit. Si vous voulez automatiser, investissez dans un module avec cron intégré : c’est 20 à 50 € pour des années de tranquillité.

Dans les deux cas, sauvegarde avant. Je sais, je me répète. Mais on a vu des marchands vider la mauvaise table parce qu’ils avaient confondu ps_cart et ps_category. Une sauvegarde, même d’une base trop lourde, se compte en minutes. Une restauration de catalogue depuis zéro, c’est des jours.

Comment automatiser le nettoyage de votre base de données PrestaShop ?

Nettoyer une fois, c’est bien. Mettre en place un nettoyage automatique, c’est ce qui fait la différence entre une boutique qui tient dans le temps et une qui retombe dans le même piège tous les 6 mois.

Option 1 : un module avec tâche cron

Les modules Comonsoft et PrestaToolbox permettent de configurer une URL de cron que vous ajoutez dans le planificateur de tâches de votre hébergeur (cPanel → Tâches Cron, ou Plesk → Tâches planifiées). Vous définissez une fréquence (une fois par mois suffit) et le module se charge du nettoyage. Aucune intervention manuelle.

Option 2 : un event MySQL planifié (pour les VPS)

Si vous avez un VPS ou un serveur dédié avec un accès MySQL direct, vous pouvez créer un event planifié qui nettoie automatiquement les tables. C’est une solution propre et gratuite :

CREATE EVENT `nettoyage_ps_connections`
ON SCHEDULE EVERY 1 MONTH
DO DELETE FROM ps_connections
WHERE date_add < NOW() - INTERVAL 90 DAY;

Vous créez un event par table à nettoyer. C’est propre, c’est natif MySQL, et ça tourne tout seul, à condition que le planificateur soit actif (SHOW VARIABLES LIKE 'event_scheduler' doit afficher ON). Par contre, ça demande les privilèges EVENT sur votre serveur MySQL, ce que les hébergements mutualisés ne donnent généralement pas. Pour les autres tables, reprenez la requête de leur entrée dans l’index, sans le LIMIT. Pour les paniers, créez un event par requête : les lignes orphelines partiront au passage suivant.

Option 3 : le forfait maintenance

C’est la solution qu’on propose chez CYBERIAL. Le forfait maintenance et support PrestaShop à 69 € HT/mois, sans engagement inclut le nettoyage mensuel de la base de données et la surveillance des tables critiques, y compris ps_cart_rule_combination, que personne ne regarde. Vous n’avez plus à dérouler l’index table par table : on s’en occupe, avec des sauvegardes quotidiennes gardées 30 jours.

Une routine de maintenance BDD en 3 points

Pour ceux qui veulent gérer le nettoyage de leur base de données PrestaShop eux-mêmes, voici la routine minimale :

Une fois par mois : connectez-vous à phpMyAdmin, triez les tables par taille. Si une table de la liste verte dépasse 100 Mo, nettoyez-la, après une sauvegarde, en suivant son entrée dans l’index des tables.

Une fois par trimestre : nettoyez les tables oranges (paniers abandonnés, prix expirés). Et vérifiez la taille de ps_cart_rule_combination si vous utilisez des codes promo.

Tout de suite : si vous utilisez Google Analytics ou Matomo (et vous devriez), allez dans votre back-office PrestaShop, Modules → cherchez « Récupération des données statistiques » (« Data mining for statistics » si votre back-office est en anglais) et désactivez-le. C’est ce module natif qui alimente les tables ps_connections et ps_guest. En le désactivant, vous coupez le robinet à la source. Les données arrivent dans GA/Matomo de toute façon : PrestaShop n’a pas besoin de les stocker en double.

Découvrez une vue d’ensemble sur l’optimisation PrestaShop si vous voulez faire un diagnostic complet de la performance de votre boutique.

Votre boutique est déjà lente ou en erreur ? Voyez notre dépannage PrestaShop, ou décrivez la panne dans le formulaire en bas de cette page.

Questions fréquentes

Le module PrestaShop Cleaner existe-t-il encore ?

Non. PrestaShop a archivé ce module, dont la dernière mise à jour date de février 2021. Son bouton « Nettoyer et optimiser » supprimait seulement les paniers sans commande de plus d’un mois et les règles de panier de plus d’un mois inactives, épuisées ou expirées : il ne touchait pas aux tables de statistiques. Un autre bouton, « Supprimer les commandes et clients », vidait bien les visites et les visiteurs, mais avec toutes vos commandes et tous vos clients. Pour vider aujourd’hui les tables qui grossissent, utilisez les requêtes de notre index des tables, plus haut dans cette page, ou un module de nettoyage récent (méthode 2).

Désactiver « Récupération des données statistiques » fait-il perdre des données ?

Non, rien n’est effacé. PrestaShop arrête seulement d’enregistrer les nouvelles visites (ps_connections, ps_connections_source, ps_connections_page) et la plupart des nouveaux visiteurs (ps_guest). Commandes, clients et paniers ne sont pas concernés. Ce qui ne bouge plus : les statistiques de visites, les « Dernières connexions » des fiches clients et le « Taux de transformation » affiché au-dessus de la liste des commandes. Si Google Analytics ou Matomo mesure déjà votre trafic, c’est le plus sûr moyen d’empêcher ces tables de grossir : désactivez le module dans le gestionnaire de modules.

Vous préférez qu’on s’en occupe ?

Décrivez en une ligne ce qui se passe : base trop lourde, boutique lente, erreur 500. Intervention dès 150 € HT, prix fixe validé avant toute intervention : ces 150 € sont déduits si vous passez ensuite à la maintenance. Pour une urgence, appelez le 09 72 03 59 17 : réponse en moins d’une heure, 7j/7, de 8 h à 22 h.

Et si vous ne voulez plus vous poser la question : la maintenance à 69 € HT/mois, sans engagement, avec un audit complet offert au démarrage. Elle inclut un nettoyage quotidien et automatique de la base de données, et le dépannage.