So beheben Sie eine langsame WordPress-Datenbank: Eine Checkliste in 4 Schritten
John Turner
John Turner
Ihr WordPress-Admin-Dashboard sollte nicht fünf Sekunden zum Laden brauchen. Wenn es das tut, liegt das Problem möglicherweise nicht an Ihrem Hosting-Plan oder Ihren Bildern. Es könnte Ihre Datenbank sein.
Ihre Datenbank schleppt leise jahrelang angesammelten Ballast mit sich herum, wie abgelaufene Transients, Tausende von Beitragsrevisionen und Autoload-Daten von Plugins, die Sie vor Jahren gelöscht haben.
Das meiste davon ist in wp-admin unsichtbar und beeinträchtigt nicht, was Besucher sehen. Aber es summiert sich und verlangsamt schließlich alles.
Ich habe Seiten diagnostiziert, bei denen ein einziges Plugin 80 Datenbankabfragen pro Seitenaufruf auslöste. Der Hoster war in Ordnung. Das Caching war korrekt eingerichtet. Nichts davon machte einen Unterschied, bis das eigentliche Datenbankproblem behoben war.
In diesem Beitrag zeige ich Ihnen, wie Sie den Engpass identifizieren, Datenbank-Bloat bereinigen, die schweren Tabellen reparieren, die die Bereinigung überstehen, und reduzieren, wie oft WordPress überhaupt auf die Datenbank zugreift.
Hier sind die wichtigsten Erkenntnisse:
- Ein langsames Admin-Dashboard deutet fast immer auf die Datenbank hin, nicht auf Ihren Hoster oder Ihre Bilder. Das Admin-Dashboard umgeht das Seiten-Caching, daher ist es das klarste Signal, das Sie haben.
- Beitragsrevisionen, abgelaufene Transients, verwaiste Plugin-Daten und aufgeblähte Autoload-Optionen sind die häufigsten Ursachen und sie sind in wp-admin normalerweise sichtbar.
- Query Monitor (kostenlos) identifiziert, welches Plugin oder welche Abfrage der Engpass ist, bevor Sie etwas löschen.
- DB Optimizer gibt Ihrer Datenbank eine Gesundheitsbewertung in fünf Kategorien und zeigt eine vollständige Vorschau dessen, was entfernt wird, bevor Sie eine Bereinigung bestätigen.
- Autoload-Daten in wp_options sollten unter 1 MB bleiben. Darüber hinaus trägt jeder Seitenaufruf unnötiges Gewicht.
- Objekt-Caching mit Redis oder Memcached kann langsame Admin-Dashboards erheblich verbessern, die das Seiten-Caching nicht erreichen kann.
- Führen Sie vor jedem größeren Backup oder jeder Migration einen Bereinigungslauf durch. Eine kleinere Datenbank bedeutet eine schnellere Übertragung und eine kleinere Backup-Datei.
Inhaltsverzeichnis
- Was verursacht eine langsame WordPress-Datenbank?
- Wie man eine langsame WordPress-Datenbank repariert
- Fehlerbehebung: Wenn die Datenbank immer noch langsam ist
- Häufig gestellte Fragen (FAQs)
- Ihre Datenbank wird sich nicht von selbst bereinigen
Was verursacht eine langsame WordPress-Datenbank?
Bevor Sie sich mit den Korrekturen befassen, ist es hilfreich zu wissen, womit Sie es zu tun haben. WordPress-Datenbanken verlangsamen sich aus vorhersehbaren Gründen, und die meisten Websites haben gleichzeitig mehr als einen Grund.
Beitragsrevisionen
Jedes Mal, wenn Sie einen Beitrag speichern oder aktualisieren, erstellt WordPress eine neue Kopie. Auf einer aktiven Website kann ein einzelner Beitrag Dutzende von Revisionskopien enthalten, die unbegrenzt in der Datenbank verbleiben.
Sie sind für Besucher unsichtbar, erhöhen aber das Gewicht jeder Abfrage gegen die Beitrags-Tabelle.
Abgelaufene Transienten
Plugins verwenden Transients, um Daten von externen API-Aufrufen und geplanten Aufgaben vorübergehend zu cachen. Sie sollen automatisch ablaufen und sich selbst löschen.
Oftentimes they don’t, and the expired records pile up in the wp_options table long after they serve any purpose.
Verwaiste Zeilen und übrig gebliebene Plugin-Tabellen
Wenn ein Plugin gelöscht wird, bleiben seine Daten normalerweise zurück: benutzerdefinierte Felder, Benutzer-Metadaten, Beitrags-Metadaten und manchmal ganze Datenbanktabellen, die nach dem Plugin benannt sind. Eine Website, die im Laufe der Jahre ein Dutzend Plugins durchlaufen hat, trägt die Geisterdaten jedes einzelnen.
Autoload-Daten in wp_options
Optionen, die als autoload = yes gekennzeichnet sind, werden bei jeder einzelnen Seitenanfrage geladen, bevor WordPress etwas rendert. Plugins, die diese Kennzeichnung missbrauchen, belasten jeden Seitenaufruf, einschließlich Seiten, die nichts mit diesem Plugin zu tun haben.
Die gesamten Autoload-Daten sollten unter 1 MB bleiben. Viele langsame Websites liegen bei 5 MB oder mehr.
Tabellenfragmentierung
Wenn Zeilen gelöscht werden, gibt MySQL den von ihnen belegten Speicherplatz nicht automatisch wieder frei. Mit der Zeit werden Tabellen fragmentiert und MySQL muss härter arbeiten, um sie zu lesen.
Deshalb kann die Ausführung eines „Tabelle optimieren“-Befehls die Dinge beschleunigen, auch wenn die Daten selbst sauber aussehen.
Langsame oder übermäßige Plugin-Abfragen
Einige Plugins sind einfach schlecht geschrieben. Sie führen Dutzende von Abfragen bei einem einzigen Seitenaufruf aus oder fragen Spalten ab, die nicht indiziert sind, wodurch MySQL gezwungen wird, ganze Tabellen Zeile für Zeile zu durchsuchen, anstatt zum richtigen Datensatz zu springen.
Wie man eine langsame WordPress-Datenbank repariert
Um eine langsame WordPress-Datenbank zu reparieren, müssen Sie herausfinden, was sie verlangsamt, den verursachenden Ballast entfernen, die überlebenden Tabellen nach der Bereinigung reparieren und dann reduzieren, wie oft die Datenbank überhaupt abgefragt wird.
Hier ist, was Sie tun werden:
- Schritt 1: Identifizieren Sie, was Ihre Datenbank verlangsamt: Verwenden Sie das kostenlose Plugin Query Monitor, um jede Abfrage anzuzeigen, die auf Ihrer Website ausgeführt wird, wie lange jede dauert und welches Plugin sie ausgelöst hat.
- Schritt 2: Bereinigen Sie den Datenbank-Ballast: Verwenden Sie DB Optimizer, um Ihre Datenbank in fünf Gesundheitskategorien zu bewerten, genau anzuzeigen, was entfernt wird, und sie sicher mit einem integrierten Aufbewahrungsschwellenwert zu bereinigen.
- Schritt 3: Beheben Sie überladene Tabellen: Beheben Sie Autoload-Ballast in wp_options, aktivieren Sie WooCommerce HPOS, falls relevant, prüfen Sie auf MyISAM-Tabellen, die InnoDB sein sollten, und optimieren Sie Tabellen-Overhead ohne phpMyAdmin.
- Schritt 4: Reduzieren Sie, wie oft WordPress die Datenbank abfragt: Fügen Sie Seiten-Caching hinzu, falls noch nicht geschehen, und aktivieren Sie dann Objekt-Caching mit Redis oder Memcached, um langsame Admin-Bereiche zu beheben, die Seiten-Caching nicht erreichen kann.
Schritt 1: Identifizieren Sie, was Ihre Datenbank verlangsamt
Query Monitor ist ein kostenloses Plugin, das jede Datenbankabfrage anzeigt, die auf der aktuellen Seite ausgeführt wird, wie lange jede dauert und welches Plugin oder Thema sie ausgelöst hat. Installieren Sie es aus dem WordPress-Plugin-Verzeichnis und aktivieren Sie es wie jedes andere Plugin.

Nach der Aktivierung erscheint ein neuer Eintrag in Ihrer Admin-Symbolleiste, der die Gesamtzahl der Abfragen und die Ladezeit der Seite für den jeweiligen Bildschirm anzeigt. Klicken Sie darauf, um das vollständige Panel zu öffnen.
Gehen Sie zur Registerkarte Datenbankabfragen. Suchen Sie nach Abfragen, die länger als 0,05 Sekunden dauern, und nach Plugins, die eine ungewöhnlich hohe Anzahl von Aufrufen generieren.
Query Monitor nennt das verantwortliche Plugin oder Thema direkt, sodass Sie nicht raten müssen.

Wenn ein Plugin 40 oder mehr Abfragen pro Seite generiert oder Abfragen durchweg länger als 0,05 Sekunden dauern, ist das Ihr Engpass. Deaktivieren Sie es und testen Sie erneut.
Wenn keine einzelne Abfrage hervorsticht, liegt das Problem an allgemeiner Überladung, die über die Datenbank verteilt ist, und nicht an einem bestimmten Übeltäter. Fahren Sie mit Schritt 2 fort.
Eine Sache, die Sie überprüfen sollten, bevor Sie fortfahren: Query Monitor zeigt nur das Verhalten auf der aktuellen Seite an. Führen Sie es im Admin-Dashboard, auf einer WooCommerce-Produktseite, falls vorhanden, und auf einem Standardbeitrag aus.
Langsamkeit ist oft seitenspezifisch, und ein Abfrageproblem auf der Checkout-Seite wird nicht angezeigt, während Sie sich das Dashboard ansehen.
Schritt 2: Bereinigen Sie den Datenbank-Bloat
Die meisten Leute überspringen die Datenbankbereinigung, weil sie nicht wissen, was sicher gelöscht werden kann. Dieses Zögern ist verständlich. Das Löschen des falschen Elements in einer Datenbank kann nicht rückgängig gemacht werden.
DB Optimizer löst dieses Problem, indem es Ihnen genau zeigt, was sich in Ihrer Datenbank befindet, bevor Sie etwas entfernen. Das Erste, was Sie sehen, ist ein Gesundheitswert von 0 bis 100.

Es gliedert sich in fünf Kategorien: Tabellen-Overhead, Transients, Revisionen, Autoload-Größe und Papierkorbelemente. Jede erhält einen Fortschrittsbalken und eine farbcodierte Bewertung.
Grün bedeutet, dass die Kategorie in gutem Zustand ist. Gelb bedeutet, dass sie Aufmerksamkeit erfordert. Rot bedeutet, dass sie Ihre Punktzahl nach unten zieht. Klicken Sie jederzeit auf die Schaltfläche Erneut bewerten, um sie zu aktualisieren.
Sobald Sie wissen, was die Punktzahl nach unten zieht, gehen Sie zum Tab Bereinigen. Eine Zusammenfassungsleiste oben zeigt die Anzahl der zur Bereinigung verfügbaren Elemente und den insgesamt wiederherstellbaren Speicherplatz in Ihrer gesamten Datenbank an.

Darunter zeigt jeder Bereinigungstyp (Beiträge und Seiten, Kommentare, Transients und Cache) eine Elementanzahl und eine geschätzte Größe an. Sie können genau sehen, womit Sie es zu tun haben, bevor etwas gelöscht wird.
DB Optimizer verwendet standardmäßig eine Aufbewahrungsfrist von 7 Tagen. Alles, was in der letzten Woche erstellt wurde, ist tabu, unabhängig davon, welche Bereinigungstypen Sie ausgewählt haben.

Wenn Sie sich auf eine Migration vorbereiten und einen sauberen Start wünschen, senken Sie ihn. Wenn Sie an einer sensiblen Website arbeiten und zusätzliche Vorsicht walten lassen möchten, erhöhen Sie ihn. Setzen Sie ihn nur auf 0, wenn Sie alles unabhängig vom Alter bereinigen möchten. Ihre Einstellung wird automatisch gespeichert.
Fügen Sie nach der Bereinigung eine Zeile zu Ihrer wp-config.php-Datei hinzu, um zukünftige Revisionen zu begrenzen, bevor sie sich erneut ansammeln:
define('WP_POST_REVISIONS', 3);
Fügen Sie sie oberhalb der Zeile „Das ist alles, bearbeiten beenden!“ ein. Dies begrenzt WordPress auf die Beibehaltung von drei Revisionen pro Beitrag für die Zukunft.
DB Optimizer kümmert sich um das, was bereits vorhanden ist. Diese Zeile verhindert, dass es wieder auftaucht.
Schritt 3: Behandeln Sie schwere Tabellen
Die Bereinigung entfernt lose Daten, aber zwei bestimmte Tabellen verursachen anhaltende Langsamkeit, selbst nach einer gründlichen Bereinigung: wp_options und wp_postmeta. Die verwendete Storage-Engine Ihrer Datenbank spielt hier ebenfalls eine Rolle.
Autoload-Daten in wp_options
DB Optimizer zeigt Ihre Autoload-Größe als eine seiner fünf Gesundheitskategorien an. Wenn sie nach dem Ausführen der Bereinigung immer noch über 1 MB liegt, schreibt ein Plugin aktiv Autoload-Optionen bei jedem Durchlauf. Die Bereinigung entfernt alte Einträge, kann aber nicht verhindern, dass neue hinzugefügt werden.
Verwenden Sie die Registerkarte "Query Monitor", um zu sehen, was gerade automatisch geladen wird, und identifizieren Sie dann das verantwortliche Plugin. Das Deaktivieren oder die Kontaktaufnahme mit dem Support-Team ist die Lösung.
Wp_postmeta
Diese Tabelle speichert benutzerdefinierte Feldinformationen und wird auf WooCommerce- oder ACF-lastigen Websites schnell groß.
Query Monitor kennzeichnet Abfragen gegen diese Tabelle, wenn sie ein ständiger Engpass ist. Die Behebung auf Abfrageebene ist Entwicklerarbeit, aber zu wissen, dass dies das Problem ist, ist die halbe Miete.
WooCommerce-Benutzer: HPOS aktivieren
Wenn Sie WooCommerce verwenden, gehen Sie zu WooCommerce » Einstellungen » Erweitert » Funktionen und aktivieren Sie die Hochleistungs-Auftragsspeicherung.

Dadurch werden Auftragsdaten aus wp_postmeta in dedizierte, speziell entwickelte Tabellen verschoben. Dies kann die Auftragsabfragen in jedem Geschäft mit mehr als einigen hundert Aufträgen dramatisch beschleunigen.
Nach der Aktivierung fordert WooCommerce Sie möglicherweise auf, bestehende Auftragsdaten zu migrieren. Führen Sie die Migration durch, bevor Sie fortfahren.
Speicher-Engine: MyISAM vs. InnoDB
MyISAM sperrt die gesamte Datenbanktabelle während jeder Schreiboperation, was bei jeder nennenswerten Schreiblast zu Warteschlangen führt. InnoDB sperrt nur die spezifische Zeile, die gerade beschrieben wird.
WordPress hat standardmäßig InnoDB seit MySQL 5.7, aber Websites, die von älteren Hosting-Umgebungen migriert wurden, haben manchmal immer noch MyISAM-Tabellen.
Die Registerkarte "Tabellen" des DB-Optimierers zeigt die Speicher-Engine für jede Tabelle an. Wenn Sie MyISAM-Tabellen sehen, ist die Konvertierung in InnoDB eine SQL-Änderung mit einer Zeile, aber es lohnt sich, dies an einen Entwickler zu übergeben oder Ihren Hoster zu fragen, ob er dies über sein Control Panel erledigen kann.

Tabellen-Overhead
DB Optimizer hebt jede Tabelle hervor, die Überhang aufweist, und zeigt daneben eine Schaltfläche Optimieren an. Sie können sie einzeln behandeln oder den gesamten Überhang auf einmal beseitigen.

Führen Sie dies nach der Bereinigung aus, da das Löschen von Zeilen der Grund für den Überhang ist.
Schritt 4: Reduzieren Sie, wie oft WordPress die Datenbank abfragt
Selbst eine saubere, optimierte Datenbank wird bei jedem Seitenaufruf abgefragt. Caching-Schichten fangen diese Abfragen ab, sodass die Datenbank insgesamt weniger Arbeit leisten muss.
Seiten-Caching speichert die vollständige HTML-Ausgabe einer Seite, sodass WordPress die Datenbank für diese Anfrage vollständig überspringt.
Wenn Sie kein Caching-Plugin haben, fügen Sie zuerst eines hinzu. WP Rocket, W3 Total Cache und LiteSpeed Cache erledigen dies. Seiten-Caching ist die wirkungsvollste Änderung, die Sie für Besucher im Frontend vornehmen können.
Sie sollten auch Objekt-Caching aktivieren. Objekt-Caching speichert einzelne Datenbankabfrageergebnisse im Arbeitsspeicher des Servers, sodass wiederholte Abfragen den Cache anstelle der Datenbank treffen.
Admin-Anfragen, WooCommerce-Kassen und jede Seite, die nicht vollständig gecacht werden kann, profitieren davon.
Fragen Sie Ihren Hoster, ob Redis oder Memcached verfügbar ist. Viele verwaltete WordPress-Hoster beinhalten eines oder beide.
Wenn Redis verfügbar ist, installieren Sie das Plugin Redis Object Cache und folgen Sie den Verbindungshinweisen Ihres Hosters. Das Plugin zeigt den Status Verbunden an, wenn es korrekt funktioniert.
Installieren Sie Redis Object Cache nicht, es sei denn, Ihr Hoster stellt tatsächlich einen Redis-Server bereit. Ohne eine aktive Verbindung wirft das Plugin Fehler und bietet keinen Vorteil.
Optional: WP-CLI-Befehle zur Behebung einer langsamen Datenbank
Wenn Sie WordPress über die Befehlszeile verwalten, decken diese Befehle die gleichen Bereiche ab wie die obigen Schritte, ohne eine Plugin-Oberfläche.
wp db optimize
Führt das Optimierungsdienstprogramm von MySQL für jede Tabelle in der Datenbank aus.
wp transient delete --expired
Entfernt alle abgelaufenen Transienten aus wp_options.
wp post delete $(wp post list --post_status=trash --format=ids)
Löscht dauerhaft alle Beiträge, die sich derzeit im Papierkorb befinden.
wp post delete $(wp post list --post_type='revision' --format=ids)
Löscht alle gespeicherten Beitragsrevisionen.
Erstellen Sie ein Backup mit Duplicator, bevor Sie eines davon ausführen. Sie werden sofort ohne Vorschau und ohne Bestätigungsaufforderung ausgeführt.

WP-CLI bietet nicht die Gesundheitsbewertung, die Aufbewahrungsschwellenwerte oder die Vorschauen pro Kategorie, die DB Optimizer bietet. Es bietet lediglich einen schnelleren Weg zu denselben Bereinigungsaufgaben.
Fehlerbehebung: Wenn die Datenbank immer noch langsam ist
Wenn Sie alle diese Schritte durchgearbeitet haben und die Website immer noch langsam ist, ist wahrscheinlich eines der folgenden Szenarien die Ursache.
Query Monitor zeigt keinen offensichtlichen Schuldigen
Was Sie sehen: Jede einzelne Abfrage dauert weniger als 0,05 Sekunden, aber die Seite wird immer noch langsam geladen.
Das Problem könnte das gesamte Abfragevolumen sein, nicht eine einzelne langsame Abfrage. Zweihundert Abfragen zu je 0,01 Sekunden summieren sich immer noch zu zwei vollen Sekunden Datenbankzeit, bevor etwas gerendert wird.
Überprüfen Sie die Zusammenfassungsleiste in Query Monitor. Wenn die Gesamtzahl der Abfragen bei einer Standardseite über 50 bis 75 liegt, ist dies untersuchenswert.
Deaktivieren Sie Plugins einzeln, laden Sie die Seite nach jeder Deaktivierung neu und beobachten Sie, wie die Anzahl sinkt. Das Plugin, das den größten Rückgang verursacht, ist Ihr Ziel.
Autoload-Größe bleibt nach der Bereinigung hoch
Was Sie sehen: DB Optimizer zeigt nach der Bereinigung immer noch eine Autoload-Größe von über 1 MB an.
Die Bereinigung entfernt abgelaufene und verwaiste Autoload-Einträge, kann aber nicht verhindern, dass ein Plugin neue schreibt. Wenn die Zahl bei jeder Anfrage weiter ansteigt, fügt etwas aktiv dem Autoload-Pool hinzu.
Query Monitor zeigt jede Option an, die auf der aktuellen Seite geladen wird. Achten Sie auf Einträge von Plugins, die Sie nicht kennen oder aktiv nutzen, und deaktivieren Sie diese Plugins dann einzeln und aktualisieren Sie die Punktzahl.
WooCommerce-Checkout ist nach der Bereinigung immer noch langsam
Was Sie sehen: Checkout-Seiten werden nach der Bereinigung drei bis fünf Sekunden zum Laden benötigt.
HPOS ist möglicherweise aktiviert, aber die Datenmigration ist möglicherweise nicht abgeschlossen. Gehen Sie zu WooCommerce » Status » Tools und suchen Sie nach einer Option Bestelldaten migrieren. Wenn sie vorhanden ist, führen Sie sie aus.
Unvollständige Migrationen führen dazu, dass WordPress gleichzeitig aus den alten und neuen Tabellenstrukturen liest, was langsamer ist als jede einzelne.
Wenn die Migration bereits abgeschlossen ist, ist möglicherweise ein konfliktierendes Plugin schuld daran, dass WooCommerce zu den Legacy-Bestelltabelle zurückkehrt. Deaktivieren Sie Plugins einzeln und testen Sie die Checkout-Geschwindigkeit nach jeder Deaktivierung.
Objekt-Caching zeigt Verbindung an, aber der Admin ist immer noch langsam
Was Sie sehen: Das Redis Object Cache-Plugin zeigt „Verbunden“ an, aber Admin-Seiten sind immer noch langsam.
Ein Plugin leert wahrscheinlich den Objekt-Cache bei jeder Anfrage, was den Zweck der Existenz zunichtemacht. Öffnen Sie Query Monitor und überprüfen Sie den Cache. Wenn die Cache-Trefferquote unter 80 % liegt, leert etwas aggressiv.
Identifizieren Sie es, indem Sie Plugins in Gruppen von zwei oder drei deaktivieren und nach jeder Gruppe das Verhältnis überprüfen. Wenn das Trefferverhältnis springt, enthält die letzte Gruppe, die Sie deaktiviert haben, das Problem.
Nichts funktioniert
Wenn alle vier Schritte abgeschlossen sind und sich die Leistung nicht verbessert hat, liegt das Problem wahrscheinlich außerhalb der Datenbank selbst. Unzureichender MySQL-Speicher auf Shared Hosting zwingt den Server, Festplatten-Swapping anstelle von RAM zu verwenden, was keine Bereinigung beheben kann.
Wenden Sie sich an Ihren Hoster und fragen Sie speziell nach der MySQL-Speicherzuweisung und ob die serverseitige Protokollierung langsamer Abfragen verfügbar ist. Ein Entwickler, der das Protokoll langsamer Abfragen überprüft, kann Probleme identifizieren, die Query Monitor nicht erfassen kann.
Häufig gestellte Fragen (FAQs)
Woher weiß ich, ob meine WordPress-Datenbank die Ursache für eine langsame Website ist?
Das deutlichste Signal ist ein langsames WordPress-Admin-Dashboard. Das Admin-Dashboard umgeht das Caching von Seiten, sodass, wenn es langsam geladen wird, die Datenbank fast sicher beteiligt ist. Installieren Sie Query Monitor und überprüfen Sie die Gesamtzahl der Abfragen und die Ladezeit. Eine hohe Zeit bis zum ersten Byte auf gecachten Seiten ist ein weiterer starker Indikator. Es bedeutet, dass der Server auf die Datenbank wartet, bevor er antworten kann.
Was ist eine gesunde Datenbankgröße für eine WordPress-Website?
Die Gesamtgröße der Datenbank ist allein kein zuverlässiger Leistungsindikator. Eine 500 MB große Datenbank, die sauber und gut strukturiert ist, kann schneller sein als eine 100 MB große Datenbank mit 5 MB Autoload-Daten. Konzentrieren Sie sich auf die Autoload-Größe (halten Sie sie unter 1 MB) und den Tabellen-Overhead (sollte nahe Null sein) anstatt auf die Gesamtgröße der Datenbank.
Ist es sicher, Beitragsrevisionen zu löschen?
Ja. Beitragsrevisionen sind Sicherungskopien, die WordPress während der Bearbeitung automatisch erstellt. Das Löschen beeinträchtigt keine veröffentlichten Inhalte. Der 7-Tage-Aufbewahrungsschwellenwert von DB Optimizer lässt neuere Revisionen unberührt, während ältere entfernt werden, sodass Sie nichts löschen, was Sie möglicherweise noch benötigen.
Was sind Autoload-Daten und warum verlangsamen sie WordPress?
Autoload-Daten werden in der Tabelle wp_options gespeichert und bei jeder WordPress-Seitenanfrage geladen, bevor Inhalte gerendert werden. Plugins, die große Datenmengen mit aktiviertem Autoload speichern, fügen jeder Seitenladung zusätzlichen Overhead hinzu, selbst auf Seiten, die nichts mit diesem Plugin zu tun haben. Die Gesamtzahl der Autoload-Daten unter 1 MB zu halten, ist ein zuverlässiger Maßstab für eine gesunde Website.
Was ist der Unterschied zwischen Seiten-Caching und Objekt-Caching?
Seiten-Caching speichert die vollständige HTML-Ausgabe einer Seite, sodass WordPress die Datenbank für diese Anfrage vollständig überspringt. Objekt-Caching speichert einzelne Datenbankabfrageergebnisse im Arbeitsspeicher des Servers, sodass wiederholte Abfragen aus dem Cache zurückgegeben werden, anstatt erneut gegen die Datenbank ausgeführt zu werden. Seiten-Caching hilft Frontend-Besuchern. Objekt-Caching hilft Admin-Benutzern, WooCommerce-Kassen und jeder Seite, die nicht vollständig gecacht werden kann.
Löscht die Bereinigung meiner Datenbank Inhalte, die Besucher sehen können?
Nein. Die Datenbankbereinigung entfernt Daten, die für Besucher unsichtbar sind: abgelaufene Transienten, Beitragsrevisionen, Spam-Kommentare und verwaiste Metadaten. Veröffentlichte Beiträge, Seiten, Produkte und Medien werden nicht angetastet. Dennoch, erstellen Sie ein Backup, bevor Sie eine Bereinigung durchführen. Es dauert ein paar Minuten und eliminiert jedes Risiko aus dem Prozess.
Benötige ich einen Entwickler, um meine WordPress-Datenbank zu optimieren?
Nicht für die meisten Websites. Die Schritte in dieser Anleitung behandeln die häufigsten Ursachen für langsame Datenbanken ohne SQL- oder Befehlszeilenarbeit. Möglicherweise benötigen Sie einen Entwickler, wenn Query Monitor langsame Abfragen im benutzerdefinierten Plugin- oder Theme-Code identifiziert, wenn Ihre wp_postmeta-Tabelle Indexierungsprobleme aufweist oder wenn die Konvertierung der Speicher-Engine außerhalb Ihres Komfortbereichs liegt.
Was ist HPOS und brauche ich es?
High Performance Order Storage ist eine WooCommerce-Funktion, die Bestelldaten in dedizierte Datenbanktabellen verschiebt, anstatt in die standardmäßige wp_postmeta-Tabelle. Es beschleunigt Bestellabfragen bei jedem Geschäft mit erheblichem Bestellvolumen erheblich. Aktivieren Sie es unter WooCommerce » Einstellungen » Erweitert » Funktionen. Es wird für jedes WooCommerce-Geschäft mit mehr als einigen hundert Bestellungen empfohlen.
Ihre Datenbank wird sich nicht von selbst bereinigen
Sie haben etwas getan, was die meisten WordPress-Websitebesitzer nie tun: Sie haben einen Datenbank-Engpass diagnostiziert, Daten bereinigt, die sich jahrelang angesammelt haben, spezifische Tabellen angesprochen, die anhaltende Langsamkeit verursachen, und reduziert, wie oft die Datenbank arbeiten muss.
Führen Sie zukünftig einmal im Monat den Gesundheitscheck von DB Optimizer durch. Datenbank-Bloat kehrt allmählich zurück, und ein monatlicher Durchgang verhindert, dass er sich anhäuft.
Und denken Sie daran, dass die Optimierung Ihre Datenbank dauerhaft verändert. Ein Backup, bevor Sie beginnen, ist der Unterschied zwischen einem behebbareren Fehler und einem dauerhaften.
Über 1,5 Millionen WordPress-Profis nutzen Duplicator, um ihre Websites zu sichern und zu migrieren. Der kostenlose Plan deckt vollständige Website-Backups ab und dauert etwa zwei Minuten einzurichten. Rüsten Sie auf für Cloud-Speicher, automatische Backups und ein kostenloses DB Optimizer-Plugin mit Duplicator Pro!
Wenn dieser Leitfaden hilfreich war, sind diese Beiträge auch lesenswert.
- So optimieren Sie Ihre WordPress-Datenbank
- Hier sind die Schritte zur Reparatur der WordPress-Datenbank, die ich selbst unternommen habe
- WordPress-Datenbankwartung: Was Sie wöchentlich, monatlich und vierteljährlich tun sollten
- Wie man eine WordPress-Datenbank sichert
- Das beste WordPress-Datenbankoptimierungs-Plugin, das ich je verwendet habe (plus 3 Alternativen)