Comment nettoyer les anciens paniers, logs et statistiques d’une base de données PrestaShop ?

Avec le temps, une base de données PrestaShop se remplit de données dont vous n’avez plus besoin : paniers abandonnés, lignes de panier orphelines, prix spécifiques et règles panier expirés, anciens enregistrements de connexions et invités, statistiques de recherche, logs mail et 404, vues de pages et fils clients fermés. Sans contrôle, ces tables ralentissent les requêtes et gonflent les sauvegardes. Pour les nettoyer en sécurité, utilisez Cleanup Revolution : il regroupe chaque nettoyage en tâches nommées, compte les lignes affectées avant suppression, prend en charge les aperçus dry-run par défaut, et enregistre les vraies exécutions de suppression dans l’historique de nettoyage. Commencez par les paniers abandonnés de plus de 30 jours et les anciennes statistiques de recherche/connexion, vérifiez les nombres de l’aperçu, puis supprimez par lots. Faites toujours une sauvegarde de base de données d’abord. Pour une maintenance continue, planifiez les tâches au lieu de les lancer à la main ; consultez notre guide performance PrestaShop.

Before any real cleanup, make a fresh database backup and run the module preview first. Do not delete rows manually with SQL; use Cleanup Revolution's dry-run counts, review the affected tasks, then run the cleanup from the module in controlled batches.

mysqldump -u db_user -p db_name > prestashop-before-cleanup.sql

La configuration par défaut est volontairement prudente : le dry run est activé par défaut, le mode corbeille est activé, les paniers abandonnés valent par défaut 30 jours, de nombreux logs/statistiques 90 jours, les fils clients fermés 180 jours, les comptes vides 365 jours, et le moteur utilise des tailles de lot par tâche plus une limite totale de 50000. Une tâche sans ligne à retirer est ignorée par le runner groupé, et une vraie suppression de base de données se fait par lots plutôt qu’en une énorme instruction.

Un détail d’audit log compte : les exécutions dry-run retournent le nombre affecté avant que MPRCleanupLog::record() soit appelé, donc les aperçus dry-run ne sont pas écrits dans l’historique de nettoyage. Les vrais nettoyages de base de données sont logués avec dry_run = 0. Les actions manuelles du Back Office appellent DatabaseCleanupEngine::executeTask(..., $employeeID) ou DatabaseCleanupEngine::executeAll($dryRun, $employeeID) ; elles utilisent donc la valeur par défaut trigger_type = manual et enregistrent l’ID de l’employé lorsqu’il est disponible. Le nettoyage planifié de la base de données appelle MPRCleanupRevolution::cronDBCleanup(), qui transmet DatabaseCleanupEngine::executeAll(false, null, 'cron') ; ces lignes de journal enregistrent donc trigger_type = cron sans ID d’employé.

Le moteur de nettoyage de base de données inclut des tâches nommées pour paniers abandonnés, produits de panier orphelins, statistiques de recherche, prix spécifiques expirés, règles panier expirées avec quantité zéro, anciens logs, anciennes connexions, lignes de connexion orphelines, anciens invités, logs mail, logs 404, vues de pages, fils clients fermés et cache referrer. Il a aussi des nettoyages commerciaux plus risqués comme comptes invités sans commandes, adresses orphelines et anciens comptes enregistrés sans commandes ni paniers récents. Les valeurs cron par défaut répartissent le travail entre nettoyage de base de données, nettoyage de fichiers et fenêtres d’optimisation de tables, afin que vous puissiez automatiser la maintenance sans lancer toutes les opérations lourdes à la fois.