Datenbankbereinigung: Warum Ihr PrestaShop-Shop mit der Zeit langsamer wird

Diese Frustration hören wir ständig: Ihr PrestaShop-Shop war beim Start schnell, und ein Jahr später laden dieselben Seiten nur noch schleppend. Dasselbe Hosting, dasselbe Theme, dieselben Module. Nichts, worauf Sie konkret zeigen könnten, hat sich geändert. Was ist also passiert? In einem großen Teil dieser Fälle ist der Übeltäter genau das, was sich doch geändert hat, leise und an jedem einzelnen Tag, an dem Ihr Shop geöffnet war: Ihre Datenbank. PrestaShop protokolliert standardmäßig erstaunlich viele Aktivitäten, und Tabellen, die beim Start nur ein paar hundert Zeilen enthielten, umfassen inzwischen Millionen. Abfragen, die auf einer kleinen Tabelle sofort fertig waren, werden auf einer riesigen Tabelle spürbar zur Bremse. Und weil Produktseiten, Kategorieseiten und Backoffice alle auf solche Tabellen zugreifen, breitet sich die Verlangsamung überall gleichzeitig aus.

Dieser Leitfaden dreht sich gezielt um Datenbank-Bloat, der sich mit der Zeit ansammelt, welche Tabellen wachsen, warum sie wachsen, was sich genau gefahrlos bereinigen lässt und wie Sie dabei vorgehen, ohne Ihren Shop zu beschädigen. Es ist kein allgemeiner Artikel nach dem Motto „Warum ist PrestaShop langsam?“ (Module, Hosting und Frontend-Gewicht sind eigene Ursachen. Diese behandeln wir in was PrestaShop wirklich langsam macht), und es geht auch nicht darum, langsame Abfragen mit Caching zu überdecken (Redis und Full-Page-Cache haben eigene Beiträge). Hier geht es um den Ballast, der sich in den Tabellen selbst aufbaut.

Die unten beschriebenen Bloat-Tabellen und die sichere Bereinigungsstrategie gelten für PrestaShop 1.6, 1.7, 8.x und 9.x. Welche Statistiktabellen genau vorhanden sind, hängt von Version und installierten Modulen ab. Deshalb kommt die Audit-Abfrage zuerst, messen Sie immer Ihr eigenes Schema, bevor Sie gezielt etwas bereinigen.

Warum PrestaShop-Datenbanken unbemerkt wachsen

PrestaShop wird mit einem Statistik- und Protokollsystem ausgeliefert, das deutlich mehr erfasst, als den meisten Händlern bewusst ist. Verbindungen, Gastsitzungen, interne Suchanfragen, 404-Fehler, Protokolle gesendeter E-Mails, abgebrochene Warenkörbe, wenn die entsprechenden Statistik- und Logging-Funktionen aktiv sind, landet all das in der Datenbank, und die Aufbewahrung bleibt fast vollständig Ihnen überlassen. PrestaShop hat keine eingebaute „90 Tage aufbewahren“-Regel, und das Bereinigen hängt von den eingesetzten Modulen und der Konfiguration ab. In den meisten Shops sammeln sich die Daten daher einfach immer weiter an.

Für einen mittelgroßen Shop mit 500 Besuchern pro Tag ist die Rechnung unerbittlich:

• ps_connections, eine Zeile pro Besucherverbindung. 500/Tag sind ca. 15.000/Monat, ca. 182.000/Jahr, und es hört nie auf.
• ps_connections_source, Referrer-/HTTP-Referer-Tracking für jede Verbindung; häufig größer als ps_connections selbst.
• ps_guest, eine Zeile pro eindeutigem Gast (Browser-/OS-/Bildschirm-Fingerprint), angesammelt für jeden nicht angemeldeten Besucher.
• ps_log, das Anwendungsprotokoll. Ein einziges sehr gesprächiges Modul, das Notices schreibt, kann mehrere Zeilen pro Seitenaufruf erzeugen und diese Tabelle in den Millionenbereich treiben.
• ps_pagenotfound, jeder 404-Fehler, einschließlich des unermüdlichen Bot-Traffics, der nach /wp-admin, /phpmyadmin und Ähnlichem sucht.
• ps_statssearch, jede interne Suchanfrage, die ein Besucher eingibt.
• ps_cart und ps_cart_product, jeder jemals angelegte Warenkorb, von denen die überwältigende Mehrheit nie zu einer Bestellung wurde.
• ps_mail. Ein Protokoll jeder E-Mail, die PrestaShop versendet hat.
• die nativen Statistiktabellen (ps_statssearch, ps_searchengine und in manchen Installationen ps_referrer/ps_referrer_cache), die Analyseschicht, die in PrestaShop selbst fast niemand tatsächlich liest, weil stattdessen Google Analytics genutzt wird. Welche dieser Tabellen existieren, hängt von Ihrer PrestaShop-Version, den installierten Statistikmodulen und der Upgrade-Historie der Datenbank ab. Prüfen Sie deshalb das tatsächliche Schema, bevor Sie eine dieser Tabellen anvisieren, statt von einer festen Liste auszugehen.

Die Konsequenz ist schlicht: Nach zwei oder drei Jahren enthalten diese Tabellen regelmäßig Millionen von Zeilen, der Working Set von MySQL passt nicht mehr bequem in den Arbeitsspeicher, der InnoDB Buffer Pool gerät unter Druck, und selbst sauber indizierte Abfragen werden langsamer, weil die Engine mehr Seiten von der Festplatte lesen muss. Ihr Shop ist nicht in einer Weise schwerer geworden, die ein Besucher sehen kann. Er ist dort schwer geworden, wo nur die Datenbank es spürt.

Finden Sie zuerst heraus, was in Ihrem Shop tatsächlich aufgebläht ist

SELECT table_name, table_rows, ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'ps\_%'
ORDER BY (data_length + index_length) DESC
LIMIT 20;

Bereinigen Sie nicht blind. Jeder Shop bläht an anderen Stellen auf, abhängig von Traffic-Mix und installierten Modulen. Der erste Schritt ist daher, die Tabellengrößen zu messen. Führen Sie dies in phpMyAdmin (oder Adminer oder der MySQL-CLI) aus und setzen Sie Ihren echten Datenbanknamen ein, die Abfrage listet Ihre größten Tabellen nach Zeilenzahl und Größe auf der Festplatte auf:

• SELECT table_name, table_rows, ROUND((data_length + index_length)/1024/1024, 1) AS size_mb FROM information_schema.tables WHERE table_schema = 'your_db_name' ORDER BY (data_length + index_length) DESC LIMIT 25;

Lesen Sie das Ergebnis, bevor Sie irgendetwas anfassen. Wenn Ihre größten Tabellen ps_orders, ps_order_detail und ps_product_lang sind, ist das gesunder Bloat. Echte Geschäftsdaten, die erhalten bleiben müssen. Wenn ganz oben ps_connections, ps_guest, ps_log, ps_statssearch oder ps_pagenotfound stehen, haben Sie Datenmüll gefunden, der Gigabytes wert sein kann. Diese eine Abfrage zeigt Ihnen, ob der Rest dieses Artikels überhaupt auf Sie zutrifft und welche Tabellen Sie bereinigen sollten.

Welche Tabellen Sie bereinigen sollten, und welche Sie nie anfassen dürfen

Hier werden Anleitungen schnell gefährlich, also bleiben wir präzise. Die Tabellen fallen in drei Gruppen.

Die Warenkorbtabelle braucht ein Skalpell, keinen Hammer

Der Fehler, den wir am häufigsten sehen, ist, ps_cart vollständig zu leeren, um Speicherplatz zurückzugewinnen. Tun Sie das nicht. Eine Warenkorbzeile ohne passende id_cart in ps_orders ist ein abgebrochener Warenkorb und kann entfernt werden, sobald sie alt genug ist. Ein Warenkorb, der mit einer Bestellung verknüpft ist, gehört dagegen zur Bestellhistorie. Das sichere Muster identifiziert nur verwaiste Warenkörbe, die älter als ein definiertes Zeitfenster sind, löscht anschließend zuerst deren Kindzeilen in ps_cart_product und danach die Warenkörbe selbst, damit keine verwaisten Referenzen zurückbleiben. Am zuverlässigsten ist es, vorab eine Liste der infrage kommenden id_cart-Werte zu erstellen und dann anhand dieser Liste zu löschen. Dadurch können Sie auch sauber in Batches arbeiten. Beachten Sie, dass MySQL kein LIMIT bei einem Multi-Table-(JOIN-)DELETE erlaubt. Deshalb vermeiden wir die JOIN-Form beim eigentlichen Löschen vollständig:

• CREATE TEMPORARY TABLE tmp_orphan_carts AS SELECT c.id_cart 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 60 DAY);
• DELETE FROM ps_cart_product WHERE id_cart IN (SELECT id_cart FROM tmp_orphan_carts) LIMIT 20000;, wiederholen, bis 0 betroffene Zeilen gemeldet werden.
• DELETE FROM ps_cart WHERE id_cart IN (SELECT id_cart FROM tmp_orphan_carts) LIMIT 20000;, ebenfalls wiederholen, bis 0 Zeilen gemeldet werden.
• DROP TEMPORARY TABLE tmp_orphan_carts;

Jedes DELETE zielt jetzt auf eine einzelne Tabelle ohne Join, dadurch ist LIMIT 20000 gültig und Sie können jede Anweisung erneut ausführen, bis nichts mehr übrig ist. Schließen Sie immer zuerst die Kind-Löschungen in ps_cart_product ab, bevor Sie die Elternzeilen in ps_cart löschen. Dieses Batch-Verfahren ist bewusst gewählt. Der nächste Abschnitt erklärt, warum es wichtiger ist, als es auf den ersten Blick wirkt.

So bereinigen Sie sicher, ohne den Shop lahmzulegen

Schritt 1, sichern Sie die Datenbank, ohne Ausnahme

Erstellen Sie vor jedem DELETE oder TRUNCATE ein vollständiges Daten-Backup (mysqldump oder Snapshot Ihres Hosters). PrestaShops eigenes Werkzeug Erweiterte Einstellungen → Datenbank → DB-Sicherung gibt es zwar, aber bei großen Tabellen ist ein serverseitiger mysqldump zuverlässiger. Wenn eine Bereinigung schiefgeht, ist die Wiederherstellung Ihr einziges Sicherheitsnetz, behandeln Sie sie als Pflicht, nicht als Option.

Schritt 2, löschen Sie in Batches, nicht mit einer riesigen Abfrage

DELETE FROM ps_connections
WHERE date_add < DATE_SUB(NOW(), INTERVAL 180 DAY)
LIMIT 5000;

Ein einzelnes DELETE, das zwei Millionen Zeilen entfernt, hält lange Sperren und kann Ihren Shop währenddessen für Besucher nicht mehr erreichbar wirken lassen. Arbeiten Sie in Batches von 10.000–50.000 Zeilen (das LIMIT in den Warenkorb-Abfragen oben), legen Sie zwischen den Läufen eine kurze Pause ein und wiederholen Sie den Vorgang, bis die Tabelle bereinigt ist. Wenn Sie ein Aufbewahrungsfenster statt einer leeren Tabelle möchten, etwa die letzten 90 Tage behalten und den Rest entfernen, verwenden Sie ein datumsgefiltertes DELETE wie DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY) LIMIT 50000;, wiederholt, bis 0 Zeilen gemeldet werden. Nur wenn Sie aus einer entbehrlichen Protokolltabelle wirklich alles entfernen möchten, sollten Sie zu TRUNCATE TABLE ps_connections; greifen. Das ist deutlich schneller, weil die Tabelle gelöscht und neu erstellt wird, statt Zeilen einzeln zu entfernen. Es kann aber nicht nach Datum filtern und setzt Auto-Increment zurück. Reservieren Sie es daher für das vollständige Leeren ganzer Tabellen und führen Sie es in einer abhängigkeitssicheren Reihenfolge aus, falls verwandte Tabellen aufeinander verweisen.

Schritt 3, holen Sie den Speicherplatz mit OPTIMIZE TABLE zurück

Das ist der Teil, den Händler häufig übersehen. PrestaShop nutzt InnoDB, und nach einem großen DELETE sinkt zwar die Zeilenzahl, aber die Datei auf der Festplatte schrumpft nicht. Der freigegebene Platz bleibt als interne Fragmentierung reserviert, und Abfragen können diese leeren Seiten weiterhin lesen. Sie müssen die Tabelle ausdrücklich neu aufbauen:

• OPTIMIZE TABLE ps_connections, ps_connections_source, ps_guest, ps_log, ps_pagenotfound, ps_statssearch;

Bei InnoDB baut OPTIMIZE TABLE die Tabelle neu auf und analysiert ihre Indizes erneut, wodurch die Daten defragmentiert werden. Ob der Speicherplatz tatsächlich an das Betriebssystem zurückgegeben wird, hängt von Ihrer Umgebung ab: Mit aktiviertem innodb_file_per_table, Standard bei modernen MySQL-/MariaDB-Versionen, hat jede Tabelle ihren eigenen Tablespace und der freigegebene Platz wird an das Dateisystem zurückgegeben; bei einem gemeinsam genutzten System-Tablespace geschieht das nicht. Der Neuaufbau kann die Tabelle je nach MySQL-/MariaDB-Version und Konfiguration außerdem sperren oder kopieren. Führen Sie ihn deshalb nach den Löschungen in einem Wartungsfenster oder bei wenig Traffic aus und prüfen Sie das Verhalten auf Ihrer konkreten Serverversion, bevor Sie fest mit der Speicherfreigabe rechnen.

Schritt 4. Leeren Sie den PrestaShop-Cache nur, wenn es nötig ist

Das Löschen von Zeilen aus Protokoll- und Statistiktabellen ist eine Datenbereinigung, keine Code- oder Schemaänderung. Normalerweise erfordert es daher kein Leeren des Caches, PrestaShop speichert diese rohen Protokollzeilen nicht im Cache. Leeren Sie den Cache nur, wenn Ihre Bereinigung Daten betroffen hat, die aktuell zwischengespeichert werden (zum Beispiel Dashboard-Statistiken, die ein Widget aus dem Cache versorgen), oder nach Code-, Modul- oder Schemaänderungen, die kompilierten Output tatsächlich ungültig machen. Wenn es nötig ist, nutzen Sie im Backoffice Erweiterte Einstellungen → Leistung → Cache leeren (oder löschen Sie den Inhalt von var/cache/); in Versionen mit kompiliertem Klassenindex wird dieser im Rahmen desselben Vorgangs neu aufgebaut.

Bereinigung im Backoffice statt per rohem SQL

Die Statusliste prüft PHP-Version, Module, Datenbanktabellen, Fragmentierung, bereinigbare Zeilen und Cache-Größe, jeweils als noch nicht geprüft markiert.

Die Konfiguration gehört ins Modul, nicht in ad-hoc-SQL auf dem Laptop von irgendjemandem.

Rohes SQL ist präzise, aber unnachgiebig, ein fehlender JOIN, und Sie verwaisen eine Bestellung. Wenn Sie lieber keine DELETE-Anweisungen gegen einen Live-Shop schreiben möchten, haben Sie zwei sicherere Wege innerhalb von PrestaShop:

• SQL Manager (eingebaut): Mit Erweiterte Einstellungen → Datenbank → SQL Manager können Sie die Größen-Audit-Abfrage oben und alle schreibgeschützten Prüfungen speichern und erneut ausführen. Er ist primär ein SELECT-Werkzeug, aber genau der richtige Ort, um vorher und nachher zu messen und Ihre Audit-Abfrage von Monat zu Monat griffbereit zu halten.
• Ein Wartungsmodul: Ein dediziertes Bereinigungsmodul übernimmt die Logik für verwaiste Warenkörbe, die Batch-Löschungen und den OPTIMIZE-Schritt aus einer Backoffice-Seite mit Checkboxen heraus, ohne SQL, und mit destruktiven Vorgängen hinter einer Bestätigung. Genau diesen Weg würden wir einem nicht entwickelnden Shopbetreiber empfehlen, weil er die Gefahr beseitigt, versehentlich ein DELETE auf ps_orders auszuführen.

Wofür Sie sich auch entscheiden: Die Strategie ist dieselbe wie beim SQL oben, das Werkzeug ändert nur, wie sicher Sie sie ausführen.

Machen Sie es wiederkehrend, nicht zur jährlichen Panikaktion

Bloat entsteht fortlaufend, also sollte auch die Bereinigung fortlaufend erfolgen. Ein Shop, der einmal bereinigt und dann ignoriert wird, ist innerhalb weniger Monate wieder bei denselben Zeilenzahlen. Legen Sie eine feste monatliche Routine an:

• Prüfen Sie ps_log und ps_pagenotfound kurz auf echte Probleme (wiederkehrende Fehler, tatsächlich defekte Links) und leeren Sie dann Einträge, die älter als 30 Tage sind.
• Löschen Sie verwaiste Warenkörbe, die älter als 60 Tage sind (die beiden Warenkorb-Abfragen oben), zuerst die Kindzeilen in ps_cart_product, dann die Warenkörbe.
• Löschen Sie Zeilen in ps_connections, ps_connections_source und ps_guest, die älter als 90 Tage sind, mit einem datumsgefilterten DELETE (FK ps_guest → ps_customer beachten), oder leeren Sie sie komplett per TRUNCATE, wenn Sie gar kein Aufbewahrungsfenster benötigen.
• Kürzen Sie ps_statssearch und ps_mail mit demselben datumsgefilterten DELETE-Muster auf ca. 90 Tage.
• Führen Sie OPTIMIZE TABLE auf allem aus, was Sie bereinigt haben.

Die ganze Sequenz kann in einem SQL-Skript liegen, das monatlich per Cronjob auf Ihrem Server ausgeführt wird, oder von einem Wartungsmodul nach Zeitplan laufen. Automatisierung ist der Unterschied zwischen einem Shop, der schnell bleibt, und einem, der unbemerkt wieder bei Seitenladezeiten von 4 Sekunden landet, während Sie mit dem Tagesgeschäft beschäftigt sind.

Eine Ebene tiefer: Indizes und die Abfragen selbst

Das Kürzen von Zeilen ist der Hebel mit der größten Wirkung, weil es jeden Tabellenscan gleichzeitig verkleinert. Zwei verwandte Themen sind dennoch erwähnenswert, damit die Grenze klar ist:

• Fehlende Indizes in Drittanbieter-Modulen. Viele Module erstellen eigene Tabellen, ohne die Spalten zu indizieren, nach denen sie filtern. Aktivieren Sie das Slow Query Log von MySQL, achten Sie auf Abfragen, die eine Modultabelle vollständig scannen, und setzen Sie einen Index auf die WHERE-/JOIN-Spalte. Eine bereinigte Tabelle mit dem richtigen Index kann aus einer 2-Sekunden-Abfrage eine Abfrage von wenigen Millisekunden machen.
• MySQL-Tuning auf Serverebene (innodb_buffer_pool_size und Verwandtes) sowie breitere Abfrageoptimierung sind ein eigenes Fachgebiet. Das gehört zu Hosting und Konfiguration und wird in Performance-Tuning von Datenbankabfragen bis Full-Page-Cache und Hosting für PrestaShop auswählen behandelt. Wenn Sie zuerst die Daten bereinigen, optimieren Sie eine schlanke Datenbank statt einer überwucherten. Machen Sie diesen Schritt also, bevor Sie einen größeren Server kaufen.

Messen Sie Vorher und Nachher, richtig

Verlassen Sie sich nicht auf „fühlt sich schneller an“. Erfassen Sie vor der Bereinigung Ihre TTFB (Time to First Byte) auf einer festen Seitenauswahl, Startseite, eine Produktseite, eine Kategorieseite und das Backoffice-Dashboard (gerade im Adminbereich tut Bloat oft am meisten weh, weil die Statistiktabellen diese Dashboard-Widgets speisen). Notieren Sie außerdem die größten Tabellen aus der Audit-Abfrage. Nach Bereinigung und OPTIMIZE messen Sie dieselben Seiten und dieselben Tabellen erneut.

Wir geben Ihnen keinen garantierten Prozentsatz, der Gewinn hängt vollständig davon ab, wie aufgebläht Ihre Datenbank am Anfang war. Ein Shop, dessen ps_connections drei Jahre Protokolle enthielt, wird einen deutlich größeren Sprung sehen als einer, der bereits sauber war. Wenn Ihre Diagnose nicht klar auf die Datenbank zeigt, beginnen Sie lieber mit einer strukturierten Langsamkeitsprüfung statt zu raten: Ist Ihr Shop langsam. Wie Sie es prüfen und was Sie tun können. Und wenn Sie sehen möchten, wie ein vollständig optimierter PrestaShop von Anfang bis Ende aussieht, haben wir ein Beispiel dokumentiert unter PageSpeed 99/100 in einem echten Shop mit 130 Modulen.

Das Prinzip gilt unabhängig vom gewählten Weg: PrestaShop protokolliert sich bereitwillig selbst in die Knie, wenn Sie es zulassen, weil nichts diese Tabellen automatisch für Sie kürzt. Finden Sie Ihren tatsächlichen Bloat, löschen Sie nur, was wirklich entbehrlich ist, holen Sie den Speicherplatz mit OPTIMIZE zurück und setzen Sie das Ganze auf einen Zeitplan. Dann behält Ihr Shop die Geschwindigkeit, die er am Starttag hatte, auch Jahre später im laufenden Betrieb, ohne eine einzige neue Anschaffung.

Häufig gestellte Fragen

Ist es sicher, ps_connections und ps_guest zu leeren?

Das Leeren von ps_connections und den zugehörigen Tabellen (ps_connections_source, ps_connections_page) ist sicher, wenn Sie die nativen PrestaShop-Statistiken nicht nutzen, diese Tabellen speisen Analysen, die die meisten Händler ohnehin durch Google Analytics ersetzen. ps_guest braucht etwas mehr Vorsicht wegen der Foreign-Key-Verknüpfung zu ps_customer; bevorzugen Sie ein datumsgefiltertes DELETE, das aktuelle Zeilen behält, statt eines blinden TRUNCATE. Was Sie niemals leeren dürfen, ist ps_cart. Abgebrochene Warenkörbe sind dort mit Warenkörben vermischt, die zu echten Bestellungen gehören. Diese Tabelle braucht das oben gezeigte Skalpell nur für verwaiste Einträge, keinen Hammer.

Ich habe Millionen Zeilen gelöscht, aber der Speicherplatz ist nicht geschrumpft. Warum?

InnoDB gibt freigegebenen Speicherplatz nach einem DELETE nicht automatisch an das Betriebssystem zurück, die Zeilenzahl sinkt, aber die Datei auf der Festplatte bleibt gleich groß, und die freigegebenen Seiten bleiben als interne Fragmentierung erhalten. Sie müssen die Tabelle mit OPTIMIZE TABLE neu aufbauen, um den Platz zurückzugewinnen. Selbst dann wird Speicherplatz nur an das Dateisystem zurückgegeben, wenn innodb_file_per_table aktiv ist (Standard bei modernen MySQL-/MariaDB-Versionen). Führen Sie OPTIMIZE nach den Löschungen in einem Zeitraum mit wenig Traffic aus, da es die Tabelle je nach Version sperren oder kopieren kann.

Muss ich nach der Datenbankbereinigung den PrestaShop-Cache leeren?

Normalerweise nein. Das Löschen von Zeilen aus Protokoll- und Statistiktabellen ist eine Datenbereinigung, keine Code- oder Schemaänderung, und PrestaShop cached diese rohen Zeilen nicht. Leeren Sie den Cache nur, wenn Ihre Bereinigung Daten betroffen hat, die aktuell von etwas gecached werden, etwa Dashboard-Statistiken, die ein gecachetes Widget versorgen, oder nach echten Code-, Modul- oder Schemaänderungen. Routinemäßiges Kürzen von Protokollen und Warenkörben erfordert das nicht.

Warum in Batches löschen statt mit einer einzigen Abfrage?

Ein einzelnes DELETE, das zwei Millionen Zeilen entfernt, hält lange Sperren und kann Ihren Shop während der Ausführung einfrieren. Wenn Sie in Batches von 10.000–50.000 Zeilen mit einer kurzen Pause dazwischen arbeiten, bleiben die Sperren kurz und der Shop reaktionsfähig. Verwenden Sie ein datumsgefiltertes DELETE mit einem LIMIT, wiederholt, bis null Zeilen gemeldet werden. TRUNCATE ist die Ausnahme. Es ist nahezu sofort fertig, weil die Tabelle gelöscht und neu erstellt wird, kann aber nicht nach Datum filtern. Reservieren Sie es daher für das vollständige Leeren einer ganzen entbehrlichen Protokolltabelle.

Bläht sich das nicht einfach wieder auf?

Ja. Genau deshalb muss die Bereinigung wiederkehrend sein. PrestaShop hat keine eingebaute Aufbewahrungsrichtlinie, also ist ein einmal bereinigter Shop innerhalb weniger Monate wieder bei denselben Zeilenzahlen. Legen Sie die Sequenz (Protokoll-/Statistik-/Warenkorbtabelle kürzen, dann OPTIMIZE) auf einen monatlichen Cronjob, oder lassen Sie ein Wartungsmodul nach Zeitplan laufen, damit die Tabellen gar nicht erst wieder unkontrolliert wachsen. Automatisierung ist der Unterschied zwischen dauerhaft schnell bleiben und dem leisen Zurückrutschen zu 4-Sekunden-Seitenladezeiten.

Weiterführende Lektüre

• Database Cleanup, führt die Logik für verwaiste Warenkörbe, Batch-Löschungen und OPTIMIZE nach Zeitplan aus dem Backoffice aus, mit angezeigten Zeilenzahlen, bevor irgendetwas gelöscht wird
• Performance Revolution, wenn die bereinigte Datenbank weiterhin TTFB-gebunden ist: Full-Page-Cache und Critical-CSS-Schicht obendrauf
• Performance-Tuning: Datenbankabfragen bis Full-Page-Cache, Indizes, EXPLAIN und InnoDB-Tuning für die schlanke Datenbank, die Sie gerade geschaffen haben
• Was PrestaShop wirklich langsam macht. Bestätigen Sie, dass Bloat Ihre Ursache ist, bevor Sie mit dem Löschen beginnen