BlogE-Commerce-Management

PrestaShop-Datenbank aufräumen: die SQL-Anleitung

Eine wachsende Datenbank bremst das Backoffice, verlängert Sicherungen und sprengt das Hosting. Welche Tabellen explodieren, welche Abfragen helfen – und welche gefährlich sind.

Presta Debug18. Juli 2026 5 Min. Lesezeit
Datenbankzylinder, deren überflüssige Schichten sich auflösen

Warum eine aufgeblähte Datenbank teuer wird

Die PrestaShop-Datenbank eines aktiven Shops wächst ununterbrochen, und der größte Teil dieses Volumens hat keinerlei fachlichen Wert. Die Folgen zeigen sich schnell: ein zähes Backoffice, Sicherungen, die das Kontingent des Hostings sprengen, eine Wiederherstellung, die ausgerechnet dann Stunden dauert, wenn es schnell gehen muss, und ein Export, der über die Verwaltungsoberfläche der Datenbank nicht mehr durchläuft.

Das Aufräumen gehört zu den Maßnahmen mit dem besten Verhältnis von Aufwand und Wirkung. Man muss nur wissen, was man löscht.

Erkennen, was ins Gewicht fällt

Messen Sie zuerst. Diese Abfrage sortiert Ihre Tabellen nach Größe:

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS taille_mo,
       table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 25;

In der großen Mehrzahl der Fälle führen dieselben Verdächtigen die Liste an:

  • ps_connections, ps_connections_source, ps_connections_page, ps_guest: die Verfolgung der Besucherwege;
  • ps_page_viewed, ps_statssearch: die mitgelieferten Statistiken;
  • ps_search_index und ps_search_word: der interne Suchindex;
  • ps_cart und ps_cart_product: die Warenkörbe, von denen die allermeisten nie zu einer Bestellung geführt haben;
  • ps_log, ps_mail, ps_customer_thread: Protokolle, E-Mail-Historien und Nachrichten, oft voller Spam.

Bevor Sie irgendetwas löschen

Legen Sie eine vollständige Sicherung an und prüfen Sie, dass sie sich zurückspielen lässt. Eine Bereinigung ist unumkehrbar.

Arbeiten Sie zuerst mit SELECT COUNT(*). Zählen Sie vor jedem geplanten Löschvorgang die betroffenen Zeilen. Ein DELETE mit einer schlecht formulierten Bedingung lässt sich nicht zurückholen.

Schalten Sie den Shop für große Bereinigungen in den Wartungsmodus, um Sperren auf Tabellen zu vermeiden, in die gerade geschrieben wird.

Löschen Sie in Paketen. Ein DELETE über Millionen von Zeilen kann das Transaktionsprotokoll überlaufen lassen. Ergänzen Sie eine Klausel LIMIT 50000 und wiederholen Sie den Vorgang.

Die unbedenklichen Bereinigungen

Die Besucherstatistiken. Sie haben nur dann Wert, wenn Sie die mitgelieferten Statistiken von PrestaShop tatsächlich nutzen – was selten der Fall ist, sobald ein externes Analysewerkzeug im Einsatz ist.

DELETE FROM ps_connections_page WHERE id_connections IN (
  SELECT id_connections FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
) LIMIT 50000;

DELETE FROM ps_connections_source WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH) LIMIT 50000;
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH) LIMIT 50000;

Halten Sie diese Reihenfolge ein: zuerst die abhängigen Tabellen, danach die übergeordnete.

Warenkörbe ohne Bestellung. Zählen Sie, bevor Sie löschen:

SELECT COUNT(*) FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_order IS NULL AND c.date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);

Löschen Sie anschließend die zugehörigen Warenkorbzeilen vor den Warenkörben selbst. Achtung: Wenn Sie Erinnerungen zu abgebrochenen Warenkörben versenden, halten Sie ein größeres Zeitfenster vor – mindestens sechs Monate.

Die Anwendungsprotokolle.

DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 50000;

Die E-Mail-Historie. Die Tabelle ps_mail dient allein dazu, nachzusehen, was versendet wurde. Ein Jahr Aufbewahrung reicht völlig aus.

Was Sie niemals löschen dürfen

Bestellungen, Rechnungen und Gutschriften. Für sie gilt eine gesetzliche Aufbewahrungspflicht. Ein Shop, in dem ps_orders zum Platzsparen bereinigt wurde, ist nicht wiederherstellbar.

Kunden mit einer zugehörigen Bestellung. Auch „inaktive“. Das Löschen zerstört Historie und Rechnungen.

Statistiktabellen, wenn ein Modul auf sie zugreift. Manche Attributions- oder Dashboard-Module lesen ps_connections. Prüfen Sie das vorher, sonst leeren Sie deren Berichte.

Konfigurationstabellen, unabhängig davon, wie groß sie wirken.

Neu indexieren und reorganisieren

Nach einer Bereinigung wird der Speicherplatz erst dann freigegeben, wenn die Tabellen reorganisiert werden:

OPTIMIZE TABLE ps_connections, ps_connections_page, ps_cart, ps_log;

Erzeugen Sie danach den Suchindex neu, über Shop-Parameter > Suche > Gesamte Datenbank neu indexieren. Bei einem großen Katalog überschreitet die Oberfläche die zulässige Ausführungszeit: Nutzen Sie dann die dafür vorgesehene URL für geplante Aufgaben oder arbeiten Sie in Paketen.

Prüfen Sie zuletzt, ob nach alten Migrationen noch Tabellen auf MyISAM liegen:

SELECT table_name, engine FROM information_schema.TABLES
WHERE table_schema = DATABASE() AND engine <> 'InnoDB';

InnoDB sperrt auf Zeilen- statt auf Tabellenebene: Die Umstellung beseitigt Blockaden, die unsichtbar, in einem aktiven Shop aber sehr real sind.

Daraus eine Routine machen

Eine jährliche Reinigung bringt wenig: Sechs Monate später ist die Datenbank wieder voll. Richten Sie eine monatliche automatische Bereinigung für Statistik- und Protokolltabellen ein, mit einer ein für alle Mal festgelegten Aufbewahrungsdauer.

Bleibt Ihr Backoffice auch nach dem Aufräumen langsam, liegt das Problem woanders: siehe unseren Beitrag darüber, wie Sie einen PrestaShop-Shop beschleunigen.

Ihre Datenbank prüfen lassen

Wir messen, räumen auf und richten die Reinigungsroutine ein – ohne jemals die buchhaltungsrelevanten Daten anzutasten. Sehen Sie sich dazu unser Angebot zur PrestaShop-Wartung an.