# Dlaczego Twoja baza PrestaShop waży 8 GB w 2026: audyt, czyszczenie i strategia retencji tabel balastowych
> Sklep PrestaShop działający 5 lat waży od 6 do 12 GB w bazie, z czego 80 % to nigdy nieczyszczone tabele balastowe. Audytujemy, mapujemy, ustalamy politykę retencji i automatyzujemy. Bez psucia sklepu.
- Strona:
- Język: pl
- Opublikowano: 2026-06-14
- Zaktualizowano: 2026-08-11
- Inne języki: [fr](https://www.datafirefly.com/2026/06/14/base-prestashop-tables-ballast-nettoyage-retention-2026/index.md), [en](https://www.datafirefly.com/en/2026/06/14/prestashop-database-ballast-tables-cleanup-retention-2026/index.md), [es](https://www.datafirefly.com/es/2026/06/14/base-prestashop-tablas-ballast-limpieza-retencion-2026/index.md), [de](https://www.datafirefly.com/de/2026/06/14/prestashop-datenbank-ballast-tabellen-bereinigung-retention-2026/index.md), [it](https://www.datafirefly.com/it/2026/06/14/database-prestashop-tabelle-zavorra-pulizia-retention-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/06/14/prestashop-database-ballasttabellen-opschonen-retentie-2026/index.md), [pt](https://www.datafirefly.com/pt/2026/06/14/base-prestashop-tabelas-lastro-limpeza-retencao-2026/index.md)
- Indeks:
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_statssearch` przyjmuje od 300 do 800 wierszy dziennie (każde wyszukiwanie wewnętrzne, nawet puste).
- `ps_connections` i `ps_connections_page` rejestrują każdą wizytę i każdą odsłonę. Licz od 5 000 do 15 000 wierszy dziennie.
- `ps_guest` tworzy rekord dla każdego nieuwierzytelnionego odwiedzającego.
- `ps_cart` przechowuje wszystkie koszyki, łącznie z porzuconymi, na zawsze. W części sklepów znajdujemy 90 % pustych koszyków z 2018 roku.
- `ps_log` przechwytuje 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:
1. `ps_statssearch`, 1,8 GB
2. `ps_connections_page`, 1,2 GB
3. `ps_pagenotfound`, 800 MB
4. `ps_connections`, 600 MB
5. `ps_log`, 400 MB
6. `ps_cart`, 350 MB
7. `ps_guest`, 300 MB
8. `ps_cart_rule` plus `ps_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**:
1. **Codzienny cron** wykonujący politykę retencji każdej tabeli.
2. **Token zabezpieczający**, żeby crona nie dało się wyzwolić z zewnątrz.
3. **Logi wykonania** pozwalające śledzić, co zostało usunięte.
4. **Powiadomienie** w razie niepowodzenia albo anomalii (nietypowy wolumen usunięć).
5. **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](https://www.datafirefly.com/pl/product/dfcleanup-nettoyage-base-prestashop/) 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](https://www.datafirefly.com/pl/2026/05/09/wydajnosc-prestashop-8-lista-kontrolna-core-web-vitals-2026-lcp-inp-cls/) po resztę obrazu oraz [przewodnik PrestaShop 9 kontra 8](https://www.datafirefly.com/pl/2026/05/01/prestashop-9-kontra-prestashop-8-zmiany/), 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](https://www.datafirefly.com/pl/solutions/prestashop/maintenance-sauvegarde-fiabilite/) oraz [zestawienie modułów przyspieszających sklep](https://www.datafirefly.com/pl/solutions/prestashop/performance-vitesse/).