Ein PrestaShop-Shop, der seit fünf Jahren in Produktion ist, wiegt selten weniger als 6 GB in der Datenbank. Viele überschreiten 12 GB. Es ist nicht der Katalog, der explodiert — ein Katalog mit 10.000 Produkten mit Varianten, Bildern und vollständigem SEO bleibt unter dem Gigabyte. Was sich aufbläht, sind die Ballast-Tabellen: technische Tabellen, die PrestaShop kontinuierlich befüllt und die kein nativer Prozess bereinigt. Nach fünf Jahren machen sie oft 70 bis 90 % des Gesamtgewichts der DB aus.
Dieser Artikel kartografiert die schuldigen Tabellen, liefert die SQL-Abfragen zur Messung des potenziellen Gewinns und erklärt, wie man eine nachhaltige Retention-Policy einrichtet, ohne den Shop zu brechen. Keine Magazin-Checkliste — die Version, die wir in Produktion tatsächlich anwenden.
Warum sich eine PrestaShop-Datenbank lautlos aufbläht
PrestaShop hat keinen Garbage Collector. Alle Tabellen, die Ereignisse erfassen — interne Suchen, Verbindungen, abgebrochene Warenkörbe, Logs, verwaiste Metadaten — wachsen linear, manchmal exponentiell, ohne dass irgendein nativer Mechanismus eine Bereinigung auslöst.
Konkret, bei einem Shop mit 2.000 Besuchern/Tag:
ps_statssearcherhält 300 bis 800 Zeilen pro Tag (jede interne Suche, auch leere).ps_connectionsundps_connections_pageerfassen jeden Besuch und jeden Seitenaufruf. Rechnen Sie mit 5.000 bis 15.000 Zeilen pro Tag.ps_guesterstellt einen Eintrag für jeden nicht authentifizierten Besucher.ps_cartbehält alle Warenkörbe — abgebrochene inklusive — für immer. In manchen Shops finden wir 90 % leere Warenkörbe aus 2018.ps_logerfasst alle Fehler und Admin-Ereignisse.
Multiplizieren Sie mit 365 Tagen und 5 Jahren: wir sprechen von zehntausenden Millionen Zeilen für null Business-Wert. Das Rohgewicht ist nicht das schlimmste Problem. Die wirklichen Kosten liegen woanders.
Die versteckten Kosten der Ballast-Tabellen
1. Query-Performance
InnoDB lädt die Indizes in den Speicher (Buffer Pool). Wenn technische Tabellen von mehreren GB den Buffer monopolisieren, werden Ihre Katalog-, Warenkorb- und Bestellabfragen langsamer. Der LCP einer Produktseite kann allein wegen MySQL-Speicherdruck 200 bis 400 ms zusätzlich brauchen.
2. Backups und Wiederherstellungen
Ein mysqldump-Dump von 12 GB dauert 30 bis 60 Minuten je nach Datenträger. Die Wiederherstellung kann 2 bis 4 Stunden dauern. Wenn das automatische Backup Ihres Hosters ein Zeitfenster überschreitet, beginnt es lautlos zu scheitern. Viele Shops entdecken, dass sie am Tag eines Vorfalls kein gültiges Backup mehr haben.
3. Blockierte Migrationen
Einen 12-GB-Shop auf PHP 8.2 auf einen neuen Server zu migrieren oder auf PrestaShop 9, erfordert den Transfer des Dumps via rsync, Wiederherstellung, Tests. Das Gewicht vervielfacht jede Operation. „Einfache“ Migrationen werden zu mehrtägigen Projekten.
4. Drittanbieter-Module, die schwerer werden
Einige Statistik-, Marketing-, ERP-Connector-Module erstellen ihre eigenen Tabellen und lassen sie unbegrenzt wachsen. ps_netreviews_, ps_advancedstats_, ps_mailchimp_ sind häufige Verdächtige. Ein Audit enthüllt oft eine 2-GB-Tabelle, die ein vor zwei Jahren deinstalliertes Modul hinterlassen hat.
Audit: wie viel wiegt Ihre Datenbank wirklich
Vor jeder Bereinigung wird gemessen. Diese Abfrage listet die Tabellen Ihrer Datenbank nach absteigender Größe:
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;Man erhält im Allgemeinen ein Ranking, das so aussieht:
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_rule+ps_cart_cart_rule— 250 MB
Beachten Sie, dass ps_product, ps_product_lang, ps_orders selten in der Top 10 erscheinen. Die tatsächlichen Business-Daten sind in einer alten PrestaShop-Datenbank in der Minderheit.
Kartierung der Ballast-Tabellen und Retention-Policy
ps_statssearch — die internen Suchen
Diese Tabelle erfasst jedes Wort, das in die Suchleiste eingegeben wird. Die Historie über 90 Tage hinaus zu behalten, hat keinen analytischen Wert: Suchtrends von 2019 erhellen nichts im Jahr 2026. Empfohlene Policy: 90 Tage Retention.
-- Audit
SELECT COUNT(*) AS total, MIN(date_add) AS aelteste
FROM ps_statssearch;
-- Löschung über 90 Tage hinaus
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_connections und ps_connections_page — Besuchshistorie
Wenn Sie GA4 oder Matomo verwenden, sind diese Tabellen redundant. PrestaShop füllt sie für sein eigenes Statistik-Modul, das niemand konsultiert. Policy: 30 Tage Retention, oder 0, wenn Sie ein externes Tool haben.
ps_pagenotfound — die 404er
Nützlich, um defekte Links zu identifizieren und 301-Weiterleitungen zu planen. Aber nach der Bearbeitung dient die Historie nichts mehr. Policy: 60 Tage Retention, nach Extraktion der wiederkehrenden 404er.
ps_cart — die abgebrochenen Warenkörbe
Subtil. Aktuelle Warenkörbe dienen dem Retargeting und den Erinnerungen. Über 90 Tage hinaus ist ein abgebrochener Warenkorb statistisch verloren. Policy: 90 Tage behalten, aber Warenkörbe, die mit Bestellungen verbunden sind, nicht anfassen (verbundene Tabelle ps_orders.id_cart).
-- Sichere Löschung: nur Warenkörbe OHNE zugehörige Bestellung
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 — nicht authentifizierte Besucher
Verbunden mit ps_customer und ps_connections. Bereinigung mit Vorsicht: ein Guest, der zum Customer konvertiert wurde, muss erhalten bleiben. Policy: Guests ohne Customer und ohne kürzliche Verbindung löschen.
ps_log — die Admin-Logs
Nützlich für kürzliches Debugging, ohne Wert nach einem Monat. Policy: 30 Tage Retention.
Verwaiste Metadaten
Wenn Sie ein Produkt löschen, behalten einige verbundene Tabellen verwaiste Zeilen: ps_image, ps_feature_product, ps_specific_price, ps_product_attachment. Dasselbe für gelöschte Kategorien, Hersteller, Lieferanten. Diese Zeilen dienen nichts und verfälschen die Joins.
-- Beispiel: verwaiste 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;Die DELETE-Falle in Produktion
Eine Million Zeilen in einer einzigen Abfrage auf einer InnoDB-Tabelle zu löschen, die von Ihrem Admin und Ihrem Front gelockt ist, ist ein garantierter Crash. Das Binary Log explodiert, die Replikation bricht ab, der Server kann in Swap gehen.
Die absolute Regel: in Stapeln von 5.000 bis 10.000 Zeilen maximal löschen, mit einer Pause von 100 ms zwischen jedem Stapel.
-- Batched-Deletion-Schleife (Pseudo-Code)
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;Und systematisch: Dry-Run vor Execute. Sie wollen wissen, wie viele Zeilen verschwinden und wie viel Platz Sie zurückgewinnen, bevor Sie klicken.
Retention automatisieren: die richtige Strategie
Die Bereinigung einmal manuell zu machen und zu vergessen, dient nichts — die Datenbank wird sich wieder aufblähen. Die Retention muss kontinuierlich und automatisch sein:
- Tägliches Cron, das die Retention-Policy jeder Tabelle ausführt.
- Sicherheits-Token, damit der Cron nicht von außen auslösbar ist.
- Ausführungs-Logs, um zu verfolgen, was gelöscht wurde.
- Benachrichtigung bei Fehler oder Anomalie (anormales Löschvolumen).
- OPTIMIZE TABLE wöchentlich auf bereinigten Tabellen, um Festplattenplatz zurückzugewinnen (sonst behält InnoDB den zugewiesenen Platz).
Unser dfcleanup-Modul: die verpackte Methode
Diese Strategie manuell zu implementieren, erfordert zwei bis drei Tage Entwicklung und ebenso viele Tests. Unser dfcleanup-Modul für PrestaShop 8 und 9 industrialisiert die gesamte hier beschriebene Methode:
- Sechs spezialisierte Cleaner: Suchen, Warenkörbe, Logs, Statistiken, verwaiste Metadaten, verwaiste Bilder. Jeder mit eigener konfigurierbarer Retention.
- Drei Modi: Audit (Read-Only), Dry-Run (verfolgte Simulation), Execute (Batched-Deletion von 5.000 Zeilen).
- Gewinn in MB vor Aktion berechnet, pro Cleaner und total.
- Cron-Task durch Token gesichert, einsatzbereit.
- Detaillierte Logs und PrestaShop-8-und-9-Kompatibilität.
Für 19 € vermeiden Sie manuelle DELETE-Abfragen und installieren eine nachhaltige Retention-Policy. Verglichen mit der Entwicklungszeit und den Kosten eines DBA-Vorfalls ist es eines der Module mit dem besten ROI im Katalog.
FAQ
Muss man nach jedem DELETE ein OPTIMIZE TABLE machen?
Nein, nicht nach jedem DELETE — es ist I/O-kostspielig und lockt die Tabelle. Einmal pro Woche oder Monat, in Off-Peak-Stunden, auf Tabellen, die eine massive Bereinigung erfahren haben. OPTIMIZE TABLE gewinnt Festplattenplatz zurück, den InnoDB nach der Löschung nicht natürlich freigibt.
Kann die Bereinigung das SEO oder die Statistiken beeinflussen?
Kein SEO-Impact: die bereinigten Tabellen sind technisch (interne Suchen, Verbindungen, Logs), nicht der Katalog oder die URL. Auf der Stats-Seite, wenn Sie GA4 oder Matomo verwenden, werden Ihre Daten bei ihnen gespeichert — die PrestaShop-DB ist redundant. Wenn Sie die nativen PS-Statistiken verwenden, konfigurieren Sie eine längere Retention (z. B. 180 Tage).
Welche Retention für abgebrochene Warenkörbe?
90 Tage reichen weitgehend aus. Warenkorb-Erinnerungs-Tools (Mail, Retargeting) lösen innerhalb von 24 bis 72 Stunden aus. Über 90 Tage hinaus ist die Wiederherstellungswahrscheinlichkeit statistisch null. Und Sie löschen nie einen in eine Bestellung umgewandelten Warenkorb — der Join ps_orders.id_cart schützt diese Daten.
Wie viel Gewinn konkret zu erwarten?
Bei einem 5 Jahre alten Shop, 2.000 Besucher/Tag, messen wir im Durchschnitt 60 bis 80 % DB-Reduktion beim ersten Durchgang. Ein 12-GB-Shop fällt auf 3 oder 4 GB zurück. Die folgenden Durchgänge stabilisieren die Datenbank auf einem Niveau nahe dem „echten Business-Gewicht“.
Ist das Modul Multi-Shop-kompatibel?
Ja. Die Cleaner respektieren den Multi-Shop-Bereich, wenn relevant (Warenkörbe, Suchen pro Shop). Globale Tabellen (Logs, Verbindungen) werden global bereinigt.
Um weiter zu gehen
Datenbankschulden sind eine der drei Hauptquellen langfristiger Performance-Degradation eines PrestaShop-Shops, zusammen mit veralteten Drittanbieter-Modulen und schlecht optimierten Bildern. Siehe auch unsere Core-Web-Vitals-2026-Checkliste für den Rest des Bildes, und den PrestaShop-9-vs-8-Leitfaden, wenn Sie eine Migration vorbereiten: die DB vor der Migration zu erleichtern, kann die Umstellungszeit durch 5 teilen.