MySQL Slow Query Log: Datenbankengpässe in PrestaShop finden

Warum die Datenbankleistung in PrestaShop wichtig ist

PrestaShop ist eine datenbankintensive Anwendung. Jede Produktseite, Kategorieliste, jedes Suchergebnis, jede Warenkorbaktualisierung und jeder Checkout-Schritt beinhaltet mehrere Datenbankabfragen. Eine typische Produktseite kann je nach Anzahl der installierten Module, der Komplexität des Produkts (Kombinationen, Eigenschaften, Anhänge) und dem Theme 50 bis 200 oder mehr SQL-Abfragen erzeugen. Wenn eine dieser Abfragen langsam läuft, verlangsamt sich die gesamte Seite, und der Effekt potenziert sich unter Last.

Die Herausforderung besteht darin, zu identifizieren, welche Abfragen tatsächlich langsam sind. Bei Hunderten von Abfragen pro Seitenaufruf können Sie nicht einfach raten. Sie brauchen Daten. Das MySQL Slow Query Log ist das direkteste und zuverlässigste Werkzeug zum Sammeln dieser Daten. Es zeichnet jede Abfrage auf, die einen von Ihnen definierten Zeitschwellenwert überschreitet, und gibt Ihnen ein klares Bild davon, wo Ihre Datenbank die meiste Zeit verbringt.

Dieser Leitfaden behandelt, wie Sie das Slow Query Log aktivieren und konfigurieren, wie Sie die Ergebnisse analysieren, wie Sie Abfrageausführungspläne interpretieren und wie Sie die gängigsten Optimierungen für PrestaShop-Datenbanken anwenden.

Das Slow Query Log aktivieren

Das Slow Query Log ist eine MySQL-Funktion, die Abfragen, die eine bestimmte Ausführungszeit überschreiten, in eine Protokolldatei schreibt. Es ist auf den meisten Installationen standardmäßig deaktiviert, da es einen geringen I/O-Overhead verursacht, aber die Leistungskosten sind im Vergleich zum diagnostischen Wert vernachlässigbar.

Konfiguration über my.cnf

Um das Slow Query Log dauerhaft zu aktivieren, fügen Sie die folgenden Zeilen zu Ihrer MySQL-Konfigurationsdatei hinzu. Auf den meisten Linux-Systemen befindet sich diese Datei unter /etc/mysql/my.cnf, /etc/my.cnf oder in einem Verzeichnis wie /etc/mysql/conf.d/:

slow_query_log = 1 aktiviert die Funktion.

slow_query_log_file = /var/log/mysql/slow-query.log gibt an, wohin das Log geschrieben wird. Stellen Sie sicher, dass der MySQL-Prozess Schreibberechtigungen für dieses Verzeichnis hat.

long_query_time = 1 setzt den Schwellenwert in Sekunden. Jede Abfrage, die länger als dieser Wert dauert, wird protokolliert. Beginnen Sie mit 1 Sekunde, um die schlimmsten Übeltäter zu erfassen, und senken Sie dann auf 0,5 oder sogar 0,1 Sekunden, wenn Sie die schlimmsten Abfragen optimiert haben und subtilere Engpässe finden möchten.

log_queries_not_using_indexes = 1 protokolliert Abfragen, die keinen Index verwenden, unabhängig davon, wie lange sie dauern. Dies ist äußerst nützlich für PrestaShop, da viele Leistungsprobleme durch vollständige Tabellenscans auf großen Tabellen verursacht werden. Dies kann jedoch bei einem ausgelasteten Shop viele Protokolleinträge erzeugen, daher sollten Sie es möglicherweise nur vorübergehend während der Analyse aktivieren und danach wieder deaktivieren.

Starten Sie MySQL nach der Bearbeitung der Konfigurationsdatei neu, damit die Änderungen wirksam werden.

Aktivierung zur Laufzeit

Sie können das Slow Query Log auch ohne MySQL-Neustart aktivieren, indem Sie SQL-Befehle ausführen. Verbinden Sie sich als Root mit MySQL und führen Sie aus:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL log_queries_not_using_indexes = 1;

Laufzeitänderungen werden sofort wirksam, bleiben aber nach einem MySQL-Neustart nicht bestehen. Dieser Ansatz ist nützlich für temporäre Analysesitzungen, in denen Sie Daten für einen bestimmten Zeitraum sammeln und die Protokollierung dann deaktivieren möchten.

Den richtigen Schwellenwert wählen

Der Wert von long_query_time bestimmt, was protokolliert wird. Ein zu hoher Wert bedeutet, dass Sie mäßig langsame Abfragen verpassen, die zusammen die Leistung beeinträchtigen. Ein zu niedriger Wert überflutet das Log mit Einträgen, die einzeln nicht problematisch sind.

Für eine erste Analyse beginnen Sie mit 1 Sekunde. Dies erfasst Abfragen, die eindeutig zu langsam sind. Nach deren Optimierung senken Sie den Schwellenwert auf 0,5 Sekunden, dann auf 0,2 Sekunden. Bei einer gut optimierten PrestaShop-Datenbank ist das Ziel, dass keine Abfrage länger als 0,1 Sekunden dauert, aber dieses Niveau zu erreichen erfordert erhebliche Optimierungsarbeit.

Bedenken Sie, dass die Abfrageausführungszeit mit der Serverlast variiert. Eine Abfrage, die unter normaler Last 0,3 Sekunden dauert, kann während eines Traffic-Spitze 2 Sekunden dauern, aufgrund von CPU-Wettbewerb, Festplatten-I/O-Engpässen oder Sperrkonflikten. Das Slow Query Log erfasst die tatsächlichen Ausführungszeiten, daher gibt Ihnen die Analyse von Logs aus Spitzenverkehrszeiten das realistischste Bild.

Das Slow Query Log analysieren

Das rohe Slow Query Log ist eine Textdatei mit Einträgen, die so aussehen:

# Time: 2024-03-15T14:22:33.456789Z
# User@Host: prestashop[prestashop] @ localhost []
# Query_time: 3.456123 Lock_time: 0.000234 Rows_sent: 1 Rows_examined: 847293
SET timestamp=1710511353;
SELECT * FROM ps_product WHERE active = 1 AND id_product NOT IN (SELECT id_product FROM ps_category_product WHERE id_category = 2);

Die wichtigen Felder sind Query_time (wie lange die Abfrage dauerte), Lock_time (wie lange sie auf eine Sperre gewartet hat), Rows_sent (wie viele Zeilen zurückgegeben wurden) und Rows_examined (wie viele Zeilen MySQL durchsuchen musste, um das Ergebnis zu finden). Eine Abfrage, die 847.293 Zeilen durchsucht, um 1 Zeile zurückzugeben, ist ein klares Zeichen für einen fehlenden Index oder eine ineffiziente Abfragestruktur.

mysqldumpslow verwenden

Das Lesen der rohen Logdatei ist bei ausgelasteten Shops, die Tausende langsamer Abfrageeinträge erzeugen, unpraktisch. Das Tool mysqldumpslow, das mit MySQL mitgeliefert wird, aggregiert und fasst Slow-Query-Log-Einträge zusammen. Es gruppiert identische Abfragen (abstrahiert von spezifischen Werten) und sortiert sie nach verschiedenen Kriterien.

Um die 10 langsamsten Abfragen nach Durchschnittszeit zu finden: mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

Um die Abfragen mit der höchsten Gesamtausführungszeit zu finden: mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

Um die Abfragen zu finden, die die meisten Zeilen durchsucht haben: mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

Das -s-Flag gibt die Sortierreihenfolge an: at für Durchschnittszeit, t für Gesamtzeit, c für Anzahl (wie oft die Abfrage vorkam), r für durchsuchte Zeilen. Das -t-Flag begrenzt die Ausgabe auf die Top-N-Abfragen.

Die nützlichste Sortierung für die erste Analyse ist nach Gesamtzeit (-s t), die Ihnen zeigt, welche Abfragen insgesamt die meiste Datenbankzeit verbrauchen. Eine Abfrage, die 0,5 Sekunden dauert, aber 1000 Mal pro Stunde ausgeführt wird, verbraucht mehr Gesamtzeit als eine Abfrage, die 5 Sekunden dauert, aber nur einmal pro Stunde ausgeführt wird.

pt-query-digest verwenden

Für eine detailliertere Analyse ist Percona Toolkits pt-query-digest das Branchenstandardtool. Es liefert weitaus detailliertere Statistiken als mysqldumpslow, einschließlich Perzentilverteilungen der Abfragezeiten, Varianzanalyse und Statistiken auf Tabellenebene.

Grundlegende Verwendung: pt-query-digest /var/log/mysql/slow-query.log

Die Ausgabe beginnt mit einem Profilabschnitt, der Abfragen nach Gesamtzeit sortiert, ähnlich wie mysqldumpslow, aber mit mehr Details. Jede Abfrage erhält dann einen detaillierten Abschnitt mit Minimum, Maximum, Durchschnitt, Median und 95. Perzentil der Ausführungszeiten sowie der Verteilung der durchsuchten und gesendeten Zeilen.

Das 95. Perzentil ist besonders wichtig für die PrestaShop-Leistung. Es sagt Ihnen die Ausführungszeit, unter die 95 % der Ausführungen fallen. Wenn der Durchschnitt 0,3 Sekunden beträgt, aber das 95. Perzentil 2,5 Sekunden, haben Sie ein Konsistenzproblem: Meistens ist die Abfrage akzeptabel, aber 5 % der Nutzer erleben eine viel langsamere Antwort.

Sie können Percona Toolkit auf Debian und Ubuntu mit apt install percona-toolkit installieren oder von der Percona-Website herunterladen. Die Installation lohnt sich auf jedem Server, auf dem Sie PrestaShop betreiben.

Häufige langsame Abfragen in PrestaShop

Bestimmte Abfragemuster tauchen wiederholt in PrestaShop-Slow-Query-Logs auf. Die Kenntnis dieser Muster hilft Ihnen, Probleme schneller zu diagnostizieren.

Vollständige Tabellenscans auf ps_product

Abfragen gegen die Tabelle ps_product ohne ordnungsgemäße Index-Nutzung gehören zu den häufigsten langsamen Abfragen. Wenn Ihr Katalog über einige tausend Produkte hinaus wächst, wird jede Abfrage, die die gesamte Produkttabelle scannt, problematisch. Achten Sie auf Abfragen mit WHERE-Klauseln auf Spalten, die nicht indiziert sind, oder Abfragen, die ps_product mit ps_product_lang und ps_product_shop verbinden, ohne die Primärschlüssel effizient zu nutzen.

Kategorieproduktlisten mit vielen Filtern

Wenn Kunden die Facettennavigation (Facettensuche) verwenden, um Produkte nach Attributen, Eigenschaften oder Preisbereichen zu filtern, erzeugt PrestaShop komplexe Abfragen, die mehrere Tabellen verbinden. Die ps_layered_*-Tabellen, die vom Facettensuchmodul verwendet werden, können zu Leistungsengpässen werden, wenn Indizes fehlen oder der Indizierungsprozess nicht kürzlich ausgeführt wurde.

Suchabfragen

PrestaShops integrierte Suche verwendet die Tabellen ps_search_word und ps_search_index. Bei Shops mit großen Katalogen und vielen Suchbegriffen werden diese Tabellen groß und Abfragen dagegen langsam. Die Suchabfrage beinhaltet typischerweise eine Volltextoperation oder mehrere LIKE-Bedingungen, die beide inhärent langsamer sind als Index-Lookups.

Warenkorb- und Bestellabfragen

Abfragen, die Warenkorb- oder Bestelldaten aggregieren, können bei Shops mit langer Geschichte langsam sein. Wenn Ihre ps_cart-Tabelle Millionen von Zeilen hat (was üblich ist, da PrestaShop für fast jeden Besucher einen neuen Warenkorb erstellt), werden Abfragen, die diese Tabelle scannen, langsam. Dasselbe gilt für ps_orders und ps_order_detail bei Shops mit hohem Volumen.

Statistik- und Berichtabfragen

Back-Office-Statistikmodule führen häufig Aggregatabfragen (SUM, COUNT, GROUP BY) über große Tabellen wie ps_orders, ps_connections und ps_page_viewed aus. Diese Abfragen können extrem langsam sein, da sie große Datensätze scannen. Bei Shops, die seit Jahren laufen, können diese Tabellen Millionen von Zeilen enthalten, und Statistikabfragen, die bei einem kleinen Datensatz problemlos funktionierten, dauern jetzt Minuten.

Modulgenierte Abfragen

Drittanbieter-Module erzeugen häufig ineffiziente Abfragen, weil Modulentwickler oft gegen kleine Datensätze testen. Ein Modul, das mit 100 Produkten perfekt funktioniert, kann bei 10.000 Produkten katastrophal langsame Abfragen erzeugen. Das Slow Query Log hilft Ihnen zu identifizieren, welche Module verantwortlich sind, da der Abfragetext oft Tabellennamen oder Muster enthält, die auf bestimmte Module hinweisen.

EXPLAIN zur Abfrageanalyse verwenden

Sobald Sie langsame Abfragen aus dem Log identifiziert haben, besteht der nächste Schritt darin zu verstehen, warum sie langsam sind. Die EXPLAIN-Anweisung zeigt Ihnen, wie MySQL plant, eine Abfrage auszuführen, einschließlich welche Indizes es verwendet, wie viele Zeilen es voraussichtlich durchsuchen muss und welche Join-Strategien es einsetzt.

EXPLAIN-Ausgabe lesen

Führen Sie EXPLAIN gefolgt von der langsamen Abfrage aus. Die Ausgabe zeigt eine Zeile pro Tabelle in der Abfrage mit diesen wichtigen Spalten:

type: Wie MySQL auf die Tabelle zugreift. Werte von gut bis schlecht: system/const (eine Zeile, praktisch kostenlos), eq_ref (eine Zeile pro Join, mit eindeutigem Index), ref (mehrere Zeilen, mit nicht-eindeutigem Index), range (Index-Bereichsscan), index (vollständiger Indexscan), ALL (vollständiger Tabellenscan). Wenn Sie ALL bei einer Tabelle mit mehr als einigen tausend Zeilen sehen, ist das fast sicher Ihr Engpass.

key: Welchen Index MySQL tatsächlich für diese Tabelle gewählt hat. Wenn dies NULL ist, wird kein Index verwendet und MySQL scannt die gesamte Tabelle.

rows: Die geschätzte Anzahl der Zeilen, die MySQL durchsuchen muss. Dies ist eine Schätzung, kein exakter Wert, gibt Ihnen aber ein Gefühl für die Größenordnung. Wenn der geschätzte Zeilenwert nahe der Gesamtzahl der Zeilen in der Tabelle liegt, haben Sie einen vollständigen Tabellenscan.

Extra: Zusätzliche Informationen über den Ausführungsplan. Achten Sie auf Using filesort (MySQL muss Ergebnisse ohne Index sortieren, was bei großen Datensätzen langsam ist), Using temporary (MySQL erstellt eine temporäre Tabelle, oft für GROUP BY oder DISTINCT-Operationen) und Using where (MySQL filtert Zeilen nach dem Lesen, was bedeutet, dass der Index die WHERE-Klausel nicht vollständig abdeckt).

EXPLAIN-Beispiel

Betrachten Sie eine langsame Abfrage: SELECT p.id_product, pl.name FROM ps_product p LEFT JOIN ps_product_lang pl ON p.id_product = pl.id_product WHERE pl.id_lang = 1 AND p.active = 1 AND p.price > 100 ORDER BY p.date_add DESC LIMIT 20

EXPLAIN für diese Abfrage könnte zeigen, dass auf die Tabelle ps_product mit Typ ALL (vollständiger Tabellenscan) zugegriffen wird, kein Schlüssel verwendet wird und die Extra-Spalte Using where; Using filesort zeigt. Dies sagt Ihnen, dass MySQL jede Zeile der Produkttabelle liest, nach aktivem Status und Preis filtert und die Ergebnisse dann nach Datum sortiert. Bei einer Tabelle mit 50.000 Produkten bedeutet dies das Lesen und Sortieren von Tausenden von Zeilen, um nur 20 zurückzugeben.

Die Lösung wäre die Erstellung eines zusammengesetzten Index auf (active, price, date_add) oder die Umstrukturierung der Abfrage, um bestehende Indizes besser zu nutzen.

Index-Optimierung für PrestaShop

Das Hinzufügen der richtigen Indizes ist der effektivste Weg, langsame Abfragen zu beschleunigen. Ein Index ermöglicht MySQL, Zeilen zu finden, ohne die gesamte Tabelle zu scannen, ähnlich wie ein Buchindex Ihnen ermöglicht, ein Thema zu finden, ohne jede Seite zu lesen.

Wann einen Index hinzufügen

Fügen Sie einen Index hinzu, wenn EXPLAIN einen vollständigen Tabellenscan (Typ ALL) bei einer Tabelle mit vielen Zeilen zeigt, wenn eine Abfrage häufig ausgeführt wird und konsistent im Slow Query Log erscheint, und wenn die WHERE-Klausel, JOIN-Bedingung oder ORDER BY-Klausel der Abfrage Spalten referenziert, die derzeit nicht indiziert sind.

Fügen Sie Indizes nicht blind hinzu. Jeder Index beschleunigt Lesevorgänge, verlangsamt aber Schreibvorgänge (INSERT, UPDATE, DELETE), da MySQL den Index bei jeder Datenänderung aktualisieren muss. PrestaShop führt viele Schreibvorgänge durch (Warenkorbaktualisierungen, Bestellerstellung, Statistik-Tracking), daher erzeugt übermäßige Indizierung eigene Leistungsprobleme.

Zusammengesetzte Indizes

Für PrestaShop-Abfragen sind zusammengesetzte (mehrspaltige) Indizes oft effektiver als einspaltige Indizes. Ein zusammengesetzter Index auf (id_shop, id_lang, active) ermöglicht MySQL die effiziente Verarbeitung von Abfragen, die nach allen drei Spalten filtern. Die Reihenfolge der Spalten im Index ist wichtig: MySQL verwendet den Index von links nach rechts, daher sollte die selektivste Spalte (die am meisten Zeilen herausfiltert) generell an erster Stelle stehen.

PrestaShops Multishop- und Mehrsprachenarchitektur bedeutet, dass viele Abfragen id_shop- und id_lang-Bedingungen enthalten. Diese Spalten erscheinen in praktisch jeder Abfrage gegen Produkt-, Kategorie- und CMS-Tabellen. Wenn Sie benutzerdefinierte Indizes hinzufügen, ist die Einbeziehung dieser Spalten oft notwendig, damit der Index nützlich ist.

Abdeckende Indizes

Ein abdeckender Index enthält alle Spalten, die eine Abfrage benötigt, sodass MySQL die gesamte Abfrage aus dem Index beantworten kann, ohne die eigentlichen Tabellendaten zu lesen. Dies wird in EXPLAIN als Using index in der Extra-Spalte angezeigt. Abdeckende Indizes bieten die bestmögliche Leistung, da das Lesen aus einem Index schneller ist als das Lesen aus der Tabelle selbst (Indizes sind kleiner und passen eher in den Speicher).

Häufige Index-Ergänzungen für PrestaShop

Mehrere Indizes, die in einer Standard-PrestaShop-Installation nicht vorhanden sind, können die Leistung bei großen Shops erheblich verbessern. Dazu gehören Indizes auf der Spalte date_add in ps_cart und ps_orders für Abfragen, die nach Datum filtern oder sortieren, zusammengesetzte Indizes auf ps_product_attribute für kombinationslastige Abfragen und Indizes auf benutzerdefinierten Spalten, die von Modulen hinzugefügt wurden und häufige Abfragen dagegen ausführen.

Überprüfen Sie vor dem Hinzufügen eines Index die Verbesserung, indem Sie die langsame Abfrage mit und ohne Index ausführen. Verwenden Sie EXPLAIN, um zu bestätigen, dass MySQL den neuen Index tatsächlich verwendet. Ein ungenutzter Index verschwendet Speicherplatz und verlangsamt Schreibvorgänge, ohne einen Nutzen zu bieten.

Verbindungsmanagement und Abfrageoptimierung

Verbindungspooling

PrestaShop verwendet standardmäßig eine einzelne Datenbankverbindung pro Anfrage. Jeder PHP-Prozess öffnet eine Verbindung zu MySQL, führt seine Abfragen aus und schließt die Verbindung, wenn die Anfrage abgeschlossen ist. Bei ausgelasteten Shops mit vielen gleichzeitigen Besuchern erzeugt dies eine hohe Rate an Verbindungsaufbau und -abbau, was Overhead verursacht.

Die MySQL-Einstellung max_connections begrenzt die Anzahl gleichzeitiger Verbindungen. Wenn Ihrem Shop die Verbindungen ausgehen, sehen Besucher "Too many connections"-Fehler. Der Standardwert ist oft 151, was für Shops mit hohem Traffic und vielen PHP-FPM-Workern unzureichend sein kann.

Um den richtigen Wert zu bestimmen, prüfen Sie die Statusvariable Max_used_connections, die Ihnen die Spitzenanzahl gleichzeitiger Verbindungen seit dem MySQL-Start anzeigt. Setzen Sie max_connections auf mindestens 20 % über diesem Spitzenwert, um Spielraum bei Traffic-Spitzen zu haben.

Abfrageoptimierungstechniken

Neben der Indizierung können mehrere Optimierungen auf Abfrageebene die PrestaShop-Datenbankleistung verbessern:

SELECT * vermeiden: Abfragen, die alle Spalten selektieren, übertragen mehr Daten als nötig zwischen MySQL und PHP. PrestaShop-Kern verwendet manchmal SELECT * zur Vereinfachung, aber benutzerdefinierte Abfragen sollten nur die benötigten Spalten angeben.

Unterabfragen begrenzen: MySQLs Optimizer verarbeitet Unterabfragen in vielen Fällen weniger effizient als JOINs. Wenn Sie langsame Abfragen mit IN (SELECT ...)-Mustern sehen, verbessert das Umschreiben als JOINs oft die Leistung. Dies gilt besonders für von Modulen erzeugte Abfragen.

LIMIT weise einsetzen: Für paginierte Listen verwendet PrestaShop typischerweise LIMIT offset, count. Bei großen Offsets (wie Seite 500 einer Produktliste) wird dies langsam, da MySQL alle Zeilen bis zum Offset lesen und verwerfen muss. Ein effizienterer Ansatz ist die Keyset-Paginierung, bei der nach der zuletzt gesehenen ID gefiltert wird, statt einen Offset zu verwenden.

Batch-Operationen: Module, die Produkte in Schleifen verarbeiten, führen oft eine Abfrage pro Produkt aus. Das Umschreiben als Batch-Abfragen (unter Verwendung von IN-Klauseln oder CASE-Anweisungen für Updates) reduziert die Anzahl der Roundtrips zur Datenbank dramatisch.

Überwachung und laufende Optimierung

Datenbankoptimierung ist keine einmalige Aufgabe. Da Ihr Katalog wächst, sich Trafficmuster ändern und Sie neue Module installieren, tauchen neue langsame Abfragen auf. Etablieren Sie eine Routine zur Überwachung der Datenbankleistung.

Aktivieren Sie das Slow Query Log dauerhaft mit einem angemessenen Schwellenwert (0,5 bis 1 Sekunde). Überprüfen Sie das Log wöchentlich oder monatlich mit pt-query-digest. Achten Sie auf neue Abfragen, die im Log auftauchen, und auf bestehende Abfragen, deren Ausführungszeit im Laufe der Zeit zunimmt.

Überwachen Sie die wichtigsten MySQL-Leistungskennzahlen: die Bufferpool-Trefferquote (sollte über 99 % liegen), die Anzahl langsamer Abfragen pro Stunde, die durchschnittliche Abfragezeit und die Verbindungsauslastung. Diese Metriken geben Ihnen eine Frühwarnung vor Leistungsverschlechterungen, bevor sie die Nutzer beeinträchtigen.

Wenn Sie Module hinzufügen oder aktualisieren, prüfen Sie, ob sie neue langsame Abfragen einführen. Führen Sie die Funktionalität des Moduls aus, während Sie das Slow Query Log überwachen, um Probleme zu erfassen, bevor sie den Produktions-Traffic beeinträchtigen. Ein Modul, das bei einem Test-Shop mit 50 Produkten effiziente Abfragen erzeugt, kann bei einem Produktions-Shop mit 50.000 Produkten schwere Engpässe erzeugen. Testen mit Produktionsdaten in Produktionsgröße ist der einzig zuverlässige Weg, die Modulleistung zu überprüfen.

Zusammenfassung

Das MySQL Slow Query Log ist Ihr wertvollstes Werkzeug zum Finden und Beheben von Datenbankengpässen in PrestaShop. Aktivieren Sie es, setzen Sie einen angemessenen Schwellenwert und verwenden Sie Analysetools wie mysqldumpslow oder pt-query-digest, um die schlimmsten Übeltäter zu identifizieren. Verwenden Sie EXPLAIN, um zu verstehen, warum bestimmte Abfragen langsam sind, und wenden Sie gezielte Indizes an, um vollständige Tabellenscans zu eliminieren. Überwachen Sie Ihre Datenbankleistung kontinuierlich, denn Optimierung ist ein fortlaufender Prozess, da Ihr Shop wächst. Die Kombination aus Slow-Query-Log-Analyse, EXPLAIN-gesteuerter Optimierung und ordnungsgemäßer Indizierung kann einen trägen PrestaShop-Shop in einen verwandeln, der große Kataloge und hohen Traffic mit reaktionsschnellen Seitenaufrufen bewältigt.