Langsame SQL-Abfragen vom Typ „SELECT SQL_CALC_FOUND_ROWS“

Wenn Sie Langsamkeit in WordPress untersuchen, stoßen Sie möglicherweise auf Abfragen mit dieser Struktur:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
LEFT JOIN wp_postmeta
ON ( wp_posts.ID = wp_postmeta.post_id )
...

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
INNER JOIN wp_postmeta
ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1
...

Die obigen Ausschnitte dienen nur der Veranschaulichung und sind keine vollständigen, ausführbaren Abfragen. SQL_CALC_FOUND_ROWS berechnet die Gesamtzahl der Treffer für die Filter, auch wenn die Abfrage nur eine Seite mit Ergebnissen zurückgibt. Es kann mit verschiedenen Tabellen vorkommen, nicht nur mit posts und postmeta.

Wenn die Tabellen wachsen, kann eine Abfrage, die zu viele Zeilen untersucht, länger dauern und zum Engpass werden. Die Auswirkung hängt von den Daten und vom Ausführungsplan ab.

Das Vorkommen von SQL_CALC_FOUND_ROWS allein verrät nicht die Ursache. Die Kosten können von den Filtern, einem JOIN auf Metadaten, der Ergebnismenge, der Sortierung oder den vorhandenen Indizes abhängen. Finden Sie zuerst mit PHP X-Ray das Plugin, Theme oder die Anfrage, die die Abfrage erzeugt.

Bevor Sie einen Index anlegen, erstellen Sie ein wiederherstellbares Backup und führen EXPLAIN für die vollständige Abfrage aus. Prüfen Sie auch die aktuellen Indizes der Tabelle:

SHOW INDEX FROM wp_postmeta;

Ein zusammengesetzter Index wie (post_id, meta_key) kann bestimmten Ausführungsplänen helfen, ist aber keine universelle Lösung und verteuert jeden Schreibvorgang. Wenn die Analyse bestätigt, dass er fehlt, verwenden Sie ein gepflegtes Werkzeug wie Index WP MySQL For Speed oder bitten Sie den Entwickler, den Index auf einem Klon zu entwerfen und zu testen.

Wiederholen Sie nach der Änderung EXPLAIN, vergleichen Sie die Zeit über mehrere Ausführungen und prüfen Sie Einfügungen, Suchen, Verwaltung und geplante Aufgaben. Machen Sie den Index rückgängig, wenn er den Plan nicht verbessert oder andere Vorgänge verlangsamt.

Wenn der Code keine Paginierung benötigt

Bei einer eigenen, mit WP_Query erstellten Abfrage kann der Entwickler no_found_rows => true in Betracht ziehen, wenn weder die Gesamtzahl noch die Seitenzahl verwendet wird. Wenden Sie es nicht global an: Funktionen, die diese Werte benötigen, würden nicht mehr funktionieren. Die Referenz zu WP_Query beschreibt den Parameter.

Prüfen Sie auch Filter, Sortierung und die Zahl der angeforderten Ergebnisse. Bearbeiten Sie nicht den WordPress-Kern und entfernen Sie die Klausel nicht aus einer generierten Abfrage, nur weil sie im Bericht erscheint. Die Prüfung muss neben der Zeit auch Ergebnisse und Paginierung umfassen.