Jak czyścić stare koszyki, logi i statystyki z bazy danych PrestaShop?

Z czasem baza danych PrestaShop wypełnia się danymi, których już nie potrzebujesz: porzuconymi koszykami, osieroconymi wierszami koszyka, wygasłymi specific prices i cart rules, starymi rekordami połączeń i gości, statystykami wyszukiwania, logami maili i 404, wyświetleniami stron oraz zamkniętymi wątkami klientów. Bez kontroli te tabele spowalniają zapytania i powiększają backupy. Aby wyczyścić je bezpiecznie, użyj Cleanup Revolution: grupuje każde czyszczenie w nazwane zadania, liczy objęte wiersze przed usunięciem, domyślnie obsługuje podglądy dry-run i zapisuje rzeczywiste uruchomienia usuwania w historii czyszczenia. Zacznij od porzuconych koszyków starszych niż 30 dni i nieaktualnych statystyk wyszukiwania/połączeń, sprawdź liczby w podglądzie, a potem usuwaj partiami. Zawsze najpierw wykonaj backup bazy danych. Dla stałego utrzymania zaplanuj zadania zamiast uruchamiać je ręcznie; zobacz nasz poradnik wydajności 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

Domyślna konfiguracja jest celowo konserwatywna: dry run jest domyślnie włączony, tryb trash jest włączony, porzucone koszyki domyślnie mają 30 dni, wiele logów/statystyk domyślnie ma 90 dni, zamknięte wątki klientów domyślnie mają 180 dni, puste konta domyślnie mają 365 dni, a silnik używa rozmiarów partii per zadanie oraz łącznego limitu 50000. Zadanie bez wierszy do usunięcia jest pomijane przez bulk runner, a rzeczywiste usuwanie odbywa się partiami zamiast jednym ogromnym statementem.

Jeden szczegół logu audytowego ma znaczenie: wykonania dry-run zwracają liczbę objętych wierszy przed wywołaniem MPRCleanupLog::record(), więc podglądy dry-run nie są zapisywane w historii czyszczenia. Rzeczywiste czyszczenia bazy danych są logowane z dry_run = 0. Ręczne akcje w Back Office wywołują DatabaseCleanupEngine::executeTask(..., $employeeID) lub DatabaseCleanupEngine::executeAll($dryRun, $employeeID), dlatego używają domyślnej wartości trigger_type = manual i zapisują ID pracownika, jeśli jest dostępne. Zaplanowane czyszczenie bazy danych wywołuje MPRCleanupRevolution::cronDBCleanup(), które przekazuje DatabaseCleanupEngine::executeAll(false, null, 'cron'), więc te wiersze logów zapisują trigger_type = cron bez ID pracownika.

Silnik czyszczenia bazy danych zawiera nazwane zadania dla porzuconych koszyków, osieroconych produktów koszyka, statystyk wyszukiwania, wygasłych specific prices, wygasłych cart rules z zerową ilością, starych logów, starych połączeń, osieroconych wierszy połączeń, starych gości, logów maili, logów 404, wyświetleń stron, zamkniętych wątków klientów i cache referrer. Ma też bardziej ryzykowne czyszczenia komercyjne, takie jak konta gości bez zamówień, osierocone adresy i stare zarejestrowane konta bez zamówień lub świeżych koszyków. Domyślne ustawienia cron dzielą pracę na okna czyszczenia bazy danych, czyszczenia plików i optymalizacji tabel, więc możesz automatyzować utrzymanie bez uruchamiania wszystkich ciężkich operacji naraz.