PrestaShop, übermäßige Größe der Tabelle layered_filter_block

Die Tabelle PREFIX_layered_filter_block ist der Abfrage-Cache des Moduls Facettensuche (ps_facetedsearch). Verwenden Sie das tatsächliche Präfix der Installation: Es lautet nicht immer ps_.

Prüfen Sie vor dem Leeren in phpMyAdmin die Größe jeder Tabelle und messen Sie ihre Veränderung. Die Cache-Schlüssel hängen von den tatsächlich angefragten Abfragen, Filtern und Kontexten aus Shop, Sprache, Währung und Land ab; die Größe des Katalogs allein erklärt nicht, woher das Wachstum kommt.

Der Cache wurde in ps_facetedsearch 3.x eingeführt, nicht in einer bestimmten Version des PrestaShop-Cores. Veröffentlichte Wachstumsraten beziehen sich auf Einzelfälle und sollten nicht als Erwartungswert für alle Shops gelten.

Sicherheitsupdate: ps_facetedsearch 3.0.0 bis 4.0.3 ist von GHSA-m5f5-28qr-9g9r betroffen. Aktualisieren Sie auf 4.0.4 oder neuer, bevor Sie den Cache leeren oder automatisieren. Lief im Shop eine betroffene Version, bewahren Sie die Protokolle auf und fordern Sie eine Integritätsprüfung an; die Tabelle zu leeren, beweist nicht, dass die Installation sauber ist.

Den gemessenen Cache leeren

Verwenden Sie unter Modules > Module Manager > Faceted search > Configure die Option Clear cache. Diese Aktion leert PREFIX_layered_filter_block.

PREFIX_layered_price_index ist ein eigener Index. Bauen Sie ihn nur neu auf, wenn er unvollständig oder veraltet ist, und nur in einem Wartungsfenster; den Block-Cache zu leeren, erfordert für sich allein keinen Neuaufbau der Indizes. Bei InnoDB garantiert eine kleinere logische Größe auch nicht, dass die physische Datei des Tablespace schrumpft.

Prüfen Sie nach dem Leeren Filter, Preise, Sprachen und Währungen. Messen Sie die Tabelle erneut, um zu bestätigen, dass sie die wachsende war.

Nur automatisieren, wenn sie erneut wächst

Haben Sie ein wiederkehrendes Wachstum bestätigt, kopieren Sie die spezifische URL Flush block cache, die der Cron-Bereich des Moduls anzeigt. Kopieren Sie nicht den AJAX-Link der Schaltfläche und bauen Sie die URL nicht von Hand. Das Token gewährt Zugriff auf die Aufgabe: Behandeln Sie es wie ein Zugangsdatum und veröffentlichen Sie es nicht.

curl --fail --silent --show-error --max-time 300 "URL_FLUSH_BLOCK_CACHE" >> /home/usuario_cpanel/logs/prestashop-facetas.log 2>&1

Legen Sie die Häufigkeit anhand der Messungen fest und bewahren Sie das Protokoll während der ersten Ausführungen auf. Ein Cron-Job, der still fehlschlägt, kontrolliert das Wachstum nicht und ersetzt nicht die Untersuchung des Traffics oder der Konfiguration, die so viele Schlüssel erzeugt.

Aufgabe und Wachstum prüfen

Bevor Sie das Beispiel einplanen, legen Sie ein privates Protokollverzeichnis außerhalb des Web-Roots an und ersetzen Sie URL und Benutzer. Die URL kann ein Token enthalten, das in der geplanten Aufgabe und in Prozesswerkzeugen sichtbar ist; beschränken Sie den Zugriff auf diese Konfiguration.

Eine erfolgreiche Ausgabe von curl beweist nicht, dass das Modul den Cache geleert hat: Eine Weiterleitung oder eine Fehlerseite mit Code 200 kann wie eine erfolgreiche Anfrage aussehen. Prüfen Sie den Inhalt der Antwort und vergleichen Sie Größe oder Zeilenzahl der Tabelle vorher und nachher.

Vermeiden Sie überlappende Ausführungen und passen Sie Häufigkeit und Aufbewahrung des Protokolls an. Werden die Schlüssel sofort neu erzeugt, prüfen Sie Anfragen, Filter und Kontexte, bevor Sie die Löschhäufigkeit erhöhen; ein ständig leerer Cache kann die Kosten beim Navigieren erhöhen.