Wie bereinige ich alte Warenkörbe, Logs und Statistiken aus einer PrestaShop-Datenbank?

Mit der Zeit füllt sich eine PrestaShop-Datenbank mit Daten, die Sie nicht mehr benötigen: abgebrochene Warenkörbe, verwaiste Warenkorbzeilen, abgelaufene Specific Prices und Cart Rules, alte Connection- und Guest-Datensätze, Suchstatistiken, Mail- und 404-Logs, Page Views und geschlossene Kunden-Threads. Unkontrolliert verlangsamen diese Tabellen Abfragen und blähen Backups auf. Um sie sicher zu löschen, verwenden Sie Cleanup Revolution: Es gruppiert jede Bereinigung in benannte Tasks, zählt die betroffenen Zeilen vor der Löschung, unterstützt Dry-run-Previews standardmäßig und zeichnet echte Löschläufe in der Cleanup History auf. Starten Sie mit abgebrochenen Warenkörben älter als 30 Tage und alten Such-/Connection-Statistiken, prüfen Sie die Preview Counts und löschen Sie dann in Batches. Erstellen Sie immer zuerst ein Datenbankbackup. Für laufende Pflege planen Sie Tasks, statt sie manuell auszuführen; siehe unseren PrestaShop performance guide.

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

Die Standardkonfiguration ist bewusst konservativ: Dry Run ist standardmäßig aktiviert, Trash Mode ist aktiviert, abgebrochene Warenkörbe standardmäßig 30 Tage, viele Logs/Statistiken 90 Tage, geschlossene Kundenthreads 180 Tage, leere Accounts 365 Tage, und die Engine nutzt Batch Sizes je Task plus ein Total Limit von 50000. Ein Task ohne zu entfernende Zeilen wird vom Bulk Runner übersprungen, und echte Löschung erfolgt in Batches statt als ein riesiges Statement.

Ein Audit-Log-Detail ist wichtig: Dry-run-Ausführungen geben die betroffene Anzahl zurück, bevor MPRCleanupLog::record() aufgerufen wird. Dry-run-Previews werden daher nicht in die Cleanup History geschrieben. Echte Datenbank-Cleanup-Läufe werden mit dry_run = 0 protokolliert. Manuelle Aktionen im Back Office rufen DatabaseCleanupEngine::executeTask(..., $employeeID) oder DatabaseCleanupEngine::executeAll($dryRun, $employeeID) auf, daher verwenden sie den Standardwert trigger_type = manual und speichern die Mitarbeiter-ID, wenn eine verfügbar ist. Die geplante Datenbankbereinigung ruft MPRCleanupRevolution::cronDBCleanup() auf, wodurch DatabaseCleanupEngine::executeAll(false, null, 'cron') übergeben wird. Diese Protokolleinträge speichern daher trigger_type = cron ohne Mitarbeiter-ID.

Die Database Cleanup Engine enthält benannte Tasks für abgebrochene Warenkörbe, verwaiste Cart Products, Suchstatistiken, abgelaufene Specific Prices, abgelaufene Cart Rules mit Nullmenge, alte Logs, alte Connections, verwaiste Connection Rows, alte Guests, Mail Logs, 404 Logs, Page Views, geschlossene Customer Threads und Referrer Cache. Sie hat außerdem risikoreichere kommerzielle Cleanups wie Gastkonten ohne Bestellungen, verwaiste Adressen und alte registrierte Konten ohne Bestellungen oder aktuelle Warenkörbe. Die Cron-Defaults trennen Arbeit in Datenbankbereinigung, Dateibereinigung und Tabellenoptimierungsfenster, sodass Sie Wartung automatisieren können, ohne jede schwere Operation gleichzeitig laufen zu lassen.