Sklep PrestaShop działający na produkcji od pięciu lat rzadko waży mniej niż 6 GB w bazie danych. Wiele przekracza 12 GB. To nie katalog eksploduje, bo katalog 10 000 produktów z odmianami, zdjęciami i pełnym SEO mieści się poniżej gigabajta. Rośnie co innego: tabele balastowe, czyli tabele techniczne, które PrestaShop zapełnia bez przerwy i których żaden natywny proces nie czyści. Po pięciu latach odpowiadają często za 70 do 90 % całkowitej wagi bazy.
Ten artykuł mapuje winne tabele, podaje zapytania SQL pozwalające zmierzyć potencjalny zysk i wyjaśnia, jak wdrożyć trwałą politykę retencji bez psucia sklepu. To nie jest lista kontrolna z magazynu, tylko wersja, którą realnie stosujemy na produkcji.
Dlaczego baza PrestaShop rośnie po cichu
PrestaShop nie ma odśmiecacza. Wszystkie tabele rejestrujące zdarzenia (wyszukiwania wewnętrzne, połączenia, porzucone koszyki, logi, osierocone metadane) rosną liniowo, czasem wykładniczo, a żaden natywny mechanizm nie uruchamia czyszczenia.
Konkretnie, w sklepie z 2 000 odwiedzających dziennie:
ps_statssearchprzyjmuje od 300 do 800 wierszy dziennie (każde wyszukiwanie wewnętrzne, nawet puste).ps_connectionsips_connections_pagerejestrują każdą wizytę i każdą odsłonę. Licz od 5 000 do 15 000 wierszy dziennie.ps_guesttworzy rekord dla każdego nieuwierzytelnionego odwiedzającego.ps_cartprzechowuje wszystkie koszyki, łącznie z porzuconymi, na zawsze. W części sklepów znajdujemy 90 % pustych koszyków z 2018 roku.ps_logprzechwytuje wszystkie błędy i zdarzenia administracyjne.
Pomnóż przez 365 dni i 5 lat: mówimy o dziesiątkach milionów wierszy przy zerowej wartości biznesowej. Surowa waga nie jest przy tym najgorszym problemem. Prawdziwy koszt leży gdzie indziej.
Ukryty koszt tabel balastowych
1. Wydajność zapytań
InnoDB ładuje indeksy do pamięci (buffer pool). Gdy tabele techniczne o wielkości kilku gigabajtów monopolizują bufor, Twoje zapytania o katalog, koszyk i zamówienia stają się wolniejsze. LCP karty produktu potrafi urosnąć o 200 do 400 ms wyłącznie z powodu presji pamięciowej MySQL.
2. Kopie zapasowe i przywracanie
Zrzut mysqldump o wielkości 12 GB zajmuje od 30 do 60 minut, zależnie od dysku. Przywracanie może zająć od 2 do 4 godzin. Jeśli automatyczna kopia u Twojego hostingodawcy przekroczy okno czasowe, zaczyna po cichu zawodzić. Wiele sklepów odkrywa, że nie ma już ważnej kopii zapasowej, dopiero w dniu awarii.
3. Zablokowane migracje
Migracja sklepu ważącego 12 GB na PHP 8.2 na nowy serwer albo na PrestaShop 9 wymaga przesłania zrzutu przez rsync, przywrócenia i przetestowania. Waga zwielokrotnia każdą operację. „Proste” migracje zamieniają się w kilkudniowe projekty.
4. Moduły zewnętrzne, które przybierają na wadze
Część modułów statystycznych, marketingowych i konektorów ERP tworzy własne tabele i pozwala im rosnąć w nieskończoność. Prefiksy ps_netreviews_, ps_advancedstats_ i ps_mailchimp_ to najczęstsi podejrzani. Audyt regularnie ujawnia tabelę ważącą 2 GB, zostawioną przez moduł odinstalowany dwa lata wcześniej.
Audyt: ile naprawdę waży Twoja baza
Przed jakimkolwiek czyszczeniem mierzymy. To zapytanie wypisuje tabele Twojej bazy uporządkowane malejąco według rozmiaru:
SELECT
table_name AS 'Table',
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size (MB)',
table_rows AS 'Rows'
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 30;Zwykle otrzymujesz ranking wyglądający mniej więcej tak:
ps_statssearch, 1,8 GBps_connections_page, 1,2 GBps_pagenotfound, 800 MBps_connections, 600 MBps_log, 400 MBps_cart, 350 MBps_guest, 300 MBps_cart_ruleplusps_cart_cart_rule, 250 MB
Zwróć uwagę, że ps_product, ps_product_lang i ps_orders rzadko trafiają do pierwszej dziesiątki. Rzeczywiste dane biznesowe stanowią w starej bazie PrestaShop mniejszość.
Mapa tabel balastowych i polityka retencji
ps_statssearch: wyszukiwania wewnętrzne
Ta tabela rejestruje każde słowo wpisane w pasek wyszukiwania. Trzymanie historii dłużej niż 90 dni nie ma żadnej wartości analitycznej, bo trendy wyszukiwań z 2019 roku niczego nie rozświetlają w 2026. Zalecana polityka: retencja 90 dni.
-- Audyt
SELECT COUNT(*) AS total, MIN(date_add) AS najstarszy
FROM ps_statssearch;
-- Usuwanie powyżej 90 dni
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_connections i ps_connections_page: historia wizyt
Jeśli korzystasz z GA4 albo Matomo, te tabele są redundantne. PrestaShop zapełnia je na potrzeby własnego modułu statystyk, do którego nikt nie zagląda. Polityka: retencja 30 dni albo 0, jeśli masz narzędzie zewnętrzne.
ps_pagenotfound: błędy 404
Przydatna do wykrywania zepsutych linków i planowania przekierowań 301. Po obsłużeniu historia przestaje jednak służyć czemukolwiek. Polityka: retencja 60 dni, po wcześniejszym wyciągnięciu powtarzających się 404.
ps_cart: porzucone koszyki
Subtelny przypadek. Świeże koszyki służą do remarketingu i przypomnień. Powyżej 90 dni porzucony koszyk jest statystycznie stracony. Polityka: przechowywać 90 dni, ale nie ruszać koszyków powiązanych z zamówieniami (złączenie z ps_orders.id_cart).
-- Bezpieczne usuwanie: wyłącznie koszyki BEZ powiązanego zamówienia
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_guest: nieuwierzytelnieni odwiedzający
Powiązana z ps_customer i ps_connections. Czyszczenie z ostrożnością: gość przekonwertowany na klienta musi zostać zachowany. Polityka: usuwać rekordy gości bez klienta i bez świeżego połączenia.
ps_log: logi administracyjne
Przydatne do bieżącego debugowania, bez wartości po miesiącu. Polityka: retencja 30 dni.
Osierocone metadane
Gdy usuwasz produkt, część powiązanych tabel zachowuje osierocone wiersze: ps_image, ps_feature_product, ps_specific_price, ps_product_attachment. To samo dotyczy usuniętych kategorii, producentów i dostawców. Te wiersze niczemu nie służą i zaburzają złączenia.
-- Przykład: osierocone ps_image
SELECT i.id_image FROM ps_image i
LEFT JOIN ps_product p ON p.id_product = i.id_product
WHERE p.id_product IS NULL;Pułapka polecenia DELETE na produkcji
Usunięcie miliona wierszy jednym zapytaniem na tabeli InnoDB blokowanej przez Twoje zaplecze i front to gwarancja awarii. Dziennik binarny eksploduje, replikacja się rozjeżdża, a serwer może wpaść w swap.
Zasada bezwzględna: usuwać partiami po maksymalnie 5 000 do 10 000 wierszy, z przerwą 100 ms między partiami.
-- Pętla usuwania partiami (pseudokod)
DO WHILE rows_affected > 0:
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY)
LIMIT 5000;
SLEEP 0.1;
END DO;I systematycznie: dry-run przed wykonaniem. Chcesz wiedzieć, ile wierszy zniknie i ile miejsca odzyskasz, zanim klikniesz.
Automatyzacja retencji: właściwa strategia
Ręczne posprzątanie raz i zapomnienie o temacie nic nie daje, bo baza znowu urośnie. Retencja musi być ciągła i automatyczna:
- Codzienny cron wykonujący politykę retencji każdej tabeli.
- Token zabezpieczający, żeby crona nie dało się wyzwolić z zewnątrz.
- Logi wykonania pozwalające śledzić, co zostało usunięte.
- Powiadomienie w razie niepowodzenia albo anomalii (nietypowy wolumen usunięć).
- Cotygodniowe OPTIMIZE TABLE na wyczyszczonych tabelach, aby odzyskać miejsce na dysku (inaczej InnoDB zachowuje przydzieloną przestrzeń).
Nasz moduł dfcleanup: metoda w wersji spakowanej
Wdrożenie tej strategii ręcznie wymaga dwóch do trzech dni pracy deweloperskiej i drugie tyle testów. Nasz moduł dfcleanup dla PrestaShop 8 i 9 uprzemysławia całą opisaną tu metodę:
- Sześć wyspecjalizowanych czyścicieli: wyszukiwania, koszyki, logi, statystyki, osierocone metadane, osierocone obrazy. Każdy z własną konfigurowalną retencją.
- Trzy tryby: Audyt (tylko odczyt), Dry-run (symulacja z zapisem śladu), Execute (usuwanie partiami po 5 000 wierszy).
- Zysk w MB wyliczany przed działaniem, per czyściciel i łącznie.
- Zadanie cron zabezpieczone tokenem, gotowe do użycia.
- Szczegółowe logi i zgodność z PrestaShop 8 oraz 9.
Za 19 € unikasz ręcznych zapytań DELETE i wdrażasz trwałą politykę retencji. W zestawieniu z czasem pracy deweloperskiej i kosztem awarii bazy to jeden z modułów o najlepszym zwrocie w całym katalogu.
FAQ
Czy po każdym DELETE trzeba wykonywać OPTIMIZE TABLE?
Nie, nie po każdym, bo jest to kosztowne pod względem operacji wejścia i wyjścia oraz blokuje tabelę. Raz w tygodniu albo raz w miesiącu, w godzinach niskiego ruchu, na tabelach po masowym czyszczeniu. OPTIMIZE TABLE odzyskuje miejsce na dysku, którego InnoDB nie zwalnia samoczynnie po usunięciu.
Czy czyszczenie może wpłynąć na SEO albo statystyki?
Żadnego wpływu na SEO: czyszczone tabele są techniczne (wyszukiwania wewnętrzne, połączenia, logi), a nie katalog czy adresy URL. Po stronie statystyk, jeśli korzystasz z GA4 albo Matomo, Twoje dane są przechowywane u nich, więc baza PrestaShop jest redundantna. Jeśli używasz natywnych statystyk PrestaShop, ustaw dłuższą retencję (na przykład 180 dni).
Jaka retencja dla porzuconych koszyków?
90 dni w zupełności wystarcza. Narzędzia przypominające o koszyku (e-mail, remarketing) uruchamiają się w ciągu 24 do 72 godzin. Powyżej 90 dni prawdopodobieństwo odzyskania jest statystycznie zerowe. I nigdy nie usuwasz koszyka przekonwertowanego w zamówienie, bo złączenie ps_orders.id_cart chroni te dane.
Jakiego zysku realnie oczekiwać?
W sklepie pięcioletnim, z 2 000 odwiedzających dziennie, mierzymy średnio od 60 do 80 % redukcji bazy przy pierwszym przejściu. Sklep z 12 GB schodzi do 3 albo 4 GB. Kolejne przebiegi stabilizują bazę na poziomie zbliżonym do „rzeczywistej wagi biznesowej”.
Czy moduł jest zgodny z multisklepem?
Tak. Czyściciele respektują zakres multisklepu tam, gdzie ma to sens (koszyki, wyszukiwania per sklep). Tabele globalne (logi, połączenia) czyszczone są globalnie.
Aby pójść dalej
Dług bazy danych to jedno z trzech głównych źródeł długoterminowego pogarszania wydajności sklepu PrestaShop, obok przestarzałych modułów zewnętrznych i źle zoptymalizowanych obrazów. Zobacz także naszą listę kontrolną Core Web Vitals 2026 po resztę obrazu oraz przewodnik PrestaShop 9 kontra 8, jeśli przygotowujesz migrację: odchudzenie bazy przed migracją potrafi pięciokrotnie skrócić czas przełączenia.
Aby przejść do działania: nasz wybór modułów do utrzymania, kopii zapasowych i niezawodności oraz zestawienie modułów przyspieszających sklep.
