Wenn ein Kunde langsame Administrationsvorgäne, fehlgeschlagene Checkouts oder zufällige Timeouts meldet, haben Agenturen nicht den Luxus, sich durch Dutzende von Tabellen zu wühlen oder das Verhalten von Plug-ins zurückzuverfolgen. Du musst die wahrscheinlichen Fehlerpunkte schnell erkennen und deine Aufmerksamkeit auf das konzentrieren, was wichtig ist.
In der Praxis lassen sich die meisten ernsthaften Leistungs- und Stabilitätsprobleme auf eine kleine Anzahl von Datenbanktabellen zurückführen, die mit der Zeit unkontrolliert wachsen. Auf neuen oder wenig besuchten Websites verursachen diese Tabellen keine Probleme, aber mit jahrelangen Inhalten, Plugins und Nutzeraktivitäten sind sie für eine unverhältnismäßig hohe Anzahl von Abstürzen, langsamen Abfragen und Notfall-Supporttickets verantwortlich.
Dieser Artikel befasst sich mit fünf WordPress-Datenbanktabellen (und Tabellenmustern), die von Wartungsagenturen aktiv überwacht werden sollten, weil sie am ehesten zu echten Leistungsproblemen führen, wenn Websites wachsen.
Warum Agenturen nur 20 % der Datenbank überwachen müssen
Das Pareto-Prinzip hilft, viele Betriebsabläufe zu erklären, und es gilt auch für die Wartung von WordPress-Datenbanken. In Agenturen treten Probleme nicht gleichmäßig in der gesamten Datenbank auf. Stattdessen ist eine kleine Gruppe von Tabellen für die meisten datenbankbezogenen Verlangsamungen, Abstürze und dringenden Support-Tickets verantwortlich.
Standard-WordPress-Installationen erstellen 12 Standardtabellen. Einige davon, wie z. B. die Tabellen wp_users, wp_links und die Taxonomietabellen, können jahrelang betrieben werden, ohne Probleme zu verursachen. Sie lösen in der Regel nicht die langsamen Abfragen aus, die Websites bei Traffic-Spitzen zum Absturz bringen.
Die Hochrisikotabellen haben jedoch ein gemeinsames Merkmal: Sie können Websites in großem Umfang zum Absturz bringen. Eine Website mit 100 Beiträgen kann mit einer unbegrenzten Anzahl von Überarbeitungen problemlos laufen. Dieselbe Website mit 10.000 Beiträgen und 300.000 Änderungseinträgen wird wahrscheinlich bei jedem Bearbeitungsvorgang eine Zeitüberschreitung aufweisen. Ein E-Commerce-Shop mit 50 Produkten sollte gut laufen, aber wenn man auf 5.000 Produkte skaliert, kann es sein, dass das Laden der Seiten mehrere Sekunden dauert.
Fünf Datenbankmuster, die WordPress-Websites bei der Skalierung zum Scheitern bringen
Schauen wir uns fünf Muster an, die bei der Wartung von Agenturen häufig auftreten.
Auf kleinen Websites sind sie nicht sofort gefährlich, aber wenn Inhalt, Traffic und Plugin-Aktivität zunehmen, werden sie zu den häufigsten Ursachen für langsame Abfragen, Timeouts und Stabilitätsprobleme.
wp_options: Autoload-Bloat kann Websites mit hohem Traffic zum Absturz bringen
Die Tabelle wp_options speichert Website-Einstellungen und Plugin-Konfigurationen und legt fest, welche Optionen WordPress bei jedem Seitenaufruf lädt (einschließlich gecachter Seiten). Unter den Spalten ist autoload die wichtigste:
WordPress lädt bei jeder Anfrage zuerst alle autoload-Optionen in den Speicher. Websites mit geringerem Autoload-Footprint können den Datenverkehr normalerweise bewältigen, aber mit zunehmendem Autoload verbraucht jeder Besucher mehr Speicher, als dein Server pro PHP-Prozess zur Verfügung stellt.
Wenn die Autoload-Größe zu groß wird (z. B. 3 MB oder mehr), siehst du langsame Verwaltungsbildschirme, Fehlschläge beim Checkout und 502-Fehler.
Schuld daran sind fast immer verwaiste Plugin-Einstellungen oder temporäre Cache-Einträge, so genannte Transienten. Bei aktiviertem Autoload können einige Plugin-Optionen, die du löschst, in der Tabelle wp_options verbleiben, was bedeutet, dass sie bei jeder Anfrage geladen werden. Bei Dutzenden von Plugins über Monate oder Jahre hinweg sammeln sich so verwaiste Daten an, die bei jedem Seitenaufruf geladen werden.
Mit der oben gezeigten SQL-Konsole in Database Studio kannst du eine Abfrage starten, um die Größe der automatisch geladenen Daten in Bytes zu überprüfen:
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Du kannst die Konsole auch für andere Abfragen verwenden, z. B. um die Ergebnisse der ersten Abfrage zu sortieren.
Dein Plan sollte sein, die Ergebnisse zu überprüfen, die großen Autoload-Einträge zu identifizieren und sie zu bereinigen (d.h. die Zeilen zu löschen).
wp_postmeta: E-Commerce-Websites können wegen überfüllter Metadaten abstürzen
In der Tabelle wp_postmeta werden benutzerdefinierte Felder für Beiträge, Seiten und Produkte gespeichert. Jedes Mal, wenn Inhalte gespeichert werden, können neue Metadateneinträge hinzugefügt werden. Vor allem Plugins fügen oft Dutzende von Feldern zu einem einzigen Beitrag oder Produkt hinzu.
WooCommerce speichert zum Beispiel Produktdaten in den Postmeta: Variationen, Bestand, Versanddetails und Attribute. Ein einziges Produkt mit Variationen kann Dutzende von Metadateneinträgen erzeugen. Große Produktkataloge erzeugen potenziell Millionen von Postmeta-Zeilen.
Das Ergebnis einer ausufernden wp_postmeta Tabelle ist, dass die Bearbeitungsvorgänge mit dem Laden der Daten zu kämpfen haben, die Produktfilter langsam werden und die Suchvorgänge bei der Abfrage der riesigen Tabellen ins Stocken geraten. Im Allgemeinen sind Fehler in Zeiten mit hohem Datenverkehr auf die Überfüllung von wp_postmeta zurückzuführen.
Mit der SQL-Konsole kannst du Abfragen durchführen, um überflüssige Daten auszuwählen und zu löschen, ähnlich wie bei wp_options. Du suchst nach Aspekten wie Multi-Gigabyte-Postmeta-Tabellen, vielen doppelten meta_keys und allgemein verwaisten Metadaten. Die Filteroptionen im Database Studio sind hier ebenfalls hilfreich:
Du kannst zum Beispiel nach meta_key sortieren, indem du auf den Spaltenpfeil klickst. Dadurch werden identische Schlüssel gruppiert, sodass du Muster erkennen kannst, z. B. Schlüssel von gelöschten Plugins oder ungenutzte benutzerdefinierte Felder.
wp_posts: Unbegrenzte Überarbeitungen lassen Bearbeitungsvorgänge abstürzen
Die Tabelle wp_posts speichert den Inhalt und den Revisionsverlauf. Standardmäßig speichert WordPress jede Änderung als separaten Datenbankeintrag, sodass bei der regelmäßigen Bearbeitung von Inhalten eine beträchtliche Menge zusätzlicher Daten anfällt. Auf Websites mit umfangreichen Inhalten und Bearbeitungshistorien können sich Tausende von Revisionseinträgen ansammeln.
Anfangs laufen deine Websites gut, aber viele gespeicherte Revisionen können dazu führen, dass deine Verwaltungsvorgänge beim Bearbeiten von Beiträgen sehr langsam geladen werden. WordPress speichert während der Bearbeitung alle 60 Sekunden; automatische Speicherungen können sich ebenfalls negativ auswirken, da bei langen Bearbeitungssitzungen Dutzende von automatischen Speichereinträgen entstehen.
Du kannst die Tabelle wp_posts mit den Revisionen schnell löschen (zum Beispiel):
Du kannst dann zur SQL-Konsole wechseln, um eine Abfrage auszuführen und die Revisionen zu löschen:
DELETE FROM wp_posts WHERE post_type="revision";
Es ist eine gute Idee, die Anzahl der Überarbeitungen mit deinen veröffentlichten Beiträgen zu vergleichen: einstellige Werte sind angemessen. Achte auch darauf, ob die Überarbeitungen mehr als die Hälfte der gesamten Einträge ausmachen, denn das deutet auf eine Aufblähung hin. Überarbeitungen, die von Monat zu Monat zunehmen, deuten darauf hin, dass du die Anzahl der Überarbeitungen begrenzen musst, was du durch eine schnelle Bearbeitung von wp-config.php erreichen kannst.
Plugin-Tabellen: Formulare und Logs wachsen, bis deine Websites zusammenbrechen
Fast jedes Plugin erstellt benutzerdefinierte Datenbanktabellen, aber bei Formular-, Such- und Sicherheits-Plugins ist das noch häufiger der Fall. Diese können weiter wachsen, ohne dass sie gewartet werden müssen.
Vor allem Formular-Plugins speichern standardmäßig jede Eingabe dauerhaft. Wenn deine Websites über Jahre hinweg einen konstanten Datenverkehr haben, sammeln sich Tausende von Formulareinträgen an. Darüber hinaus wachsen die Tabellen mit den Logs noch schneller. Sicherheits-Plugins protokollieren die Aktionen der Besucher, Analyse-Plugins verfolgen die Seitenaufrufe und Debugging-Tools zeichnen Fehler auf.
Wie bei vielen Problemen mit Datenbanktabellen kommt es zu Zeitüberschreitungen, aber auch zu langsamen Datenbanksicherungen und Leistungseinbußen, die nicht mit dem Datenverkehr korrelieren. Der Zusammenhang mit einer aufgeblähten Datenbank ist nicht immer offensichtlich, weil die Symptome in anderen Bereichen auftreten.
Du solltest nach Plugin-Tabellen suchen, die die Größe der WordPress-Kerntabellen erreichen oder überschreiten. Eine SQL-Abfrage kann diese für dich aufspüren:
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
Wenn eine dieser Tabellen verwaist ist, kannst du sie getrost löschen. Auch wenn das jetzt über den Rahmen dieses Beitrags hinausgeht: Wenn Tabellen so groß sind, dass sie verkleinert werden sollten, aber trotzdem auf deiner Website gebraucht werden, solltest du dich mal damit beschäftigen – vielleicht fragst du auch den Entwickler um Rat.
Action Scheduler: Fehlgeschlagene Aufgaben stapeln sich und bringen den Checkout zum Absturz
Der Action Scheduler führt im Wesentlichen Hintergrundaufgaben für WordPress aus. Er stellt Aufgaben in eine Warteschlange, arbeitet sie asynchron ab und speichert standardmäßig Erledigungsprotokolle dauerhaft.
Anhand von WooCommerce lässt sich gut nachvollziehen, wie Action Scheduler Probleme verursachen kann. Zeitüberschreitungen beim Zahlungsgateway führen zum Beispiel zu fehlgeschlagenen Aktionen, die in der Datenbank verbleiben und bei jedem Seitenaufruf abgefragt werden, um zu prüfen, ob noch etwas zu tun ist. Du kannst eine einzige fehlgeschlagene Aktion von den Tausenden hochrechnen, die ein typischer WooCommerce-Shop pro Monat erzeugt.
Die Views von Database Studio können dir helfen, diese fehlgeschlagenen Aktionen zu löschen:
Hier gibst du der Ansicht einen Titel, wählst die Tabelle wp_actionscheduler_actions und klickst dann auf den Link Bedingung hinzufügen. So kannst du nur fehlgeschlagene Aktionen anzeigen lassen, was es viel einfacher macht, sie aus der Datenbank zu entfernen.
Wie du deine wichtigen WordPress-Datenbanktabellen in 10 Minuten pro Monat verwalten kannst
Für die Kosten von ein paar Minuten pro Monat kannst du im Laufe eines Jahres weniger Datenbankmanagement betreiben. Natürlich musst du viele der Tabellen in deiner Datenbank nicht überwachen oder verwalten:
- Die Tabelle
wp_usersverursacht selten Probleme, es sei denn, du verwaltest Mitgliederseiten mit Millionen von Konten. Die Nutzerdaten wachsen in der Regel linear, ohne sich aufzublähen. - Taxonomie-Tabellen (wie
wp_terms,wp_term_taxonomy,wp_term_relationships) bleiben oft unabhängig von der Größe der Website stabil.
Unter den fünf problematischen Tabellen sind große wp_posts Tabellen auf Inhaltsseiten typisch und zu erwarten. Vergiss nicht: Tatsächlicher Inhalt ist kein Ballast.
Einrichten deines Überwachungsworkflows
Wenn du deine Datenbanktabellen exportierst, kannst du mit den Daten in anderen Anwendungen arbeiten. Du kannst dies über das Dropdown-Menü Weitere Elemente für jede Tabelle tun:
Du kannst in MyKinsta aber auch ohne Export eine Menge erreichen. Am besten nutzt du deine Zeit, wenn du die Bereinigung automatisierst und deine Datenbankmetriken manuell überprüfst. Die Ansichten in Database Studio können dir bei der Analyse helfen.
Du kannst zum Beispiel eine benutzerdefinierte Ansicht erstellen, die wp_postmeta überwacht, und Filter für bestimmte meta_key Muster hinzufügen, die du verfolgen möchtest:
Mit Database Studio kannst du Snippets in der SQL-Konsole erstellen und speichern. So kannst du eine SQL-Abfrage erstellen, um alle Tabellen nach Größe zu sortieren, und bei Bedarf darauf zugreifen:
Einige der größten Tabellen sollten wp_posts, wp_postmeta und wp_options sein. Du wirst alle Tabellen untersuchen wollen, die noch größer sind.
Die genaue Überwachung, die du einrichtest, hängt von deinen Websites und Bedürfnissen ab. Hier sind jedoch einige Bereiche, die du im Auge behalten solltest:
- Filtere
wp_optionsnach aktiven Autoloads und überprüfe dann die Gesamtgröße (entweder durch SQL-Abfragen oder durch Exportieren in CSV). Alles, was größer als 1 MB ist, sollte untersucht werden. - Überprüfe die Größe der Tabelle
wp_postmetaim Vergleich zum letzten Monat, insbesondere auf große Größenzuwächse. - Du kannst in
wp_postsnach post_type filtern, um Überarbeitungen mit Beiträgen zu vergleichen. Falls nötig, kannst du aufwp-config.phpein Limit einrichten. - Beim Aktionsplaner sollten die abgeschlossenen Aktionen die ausstehenden oder fehlgeschlagenen Aktionen übertreffen.
Zusammenfassend lässt sich sagen, dass du mit Database Studio die Ansichten, Filter und Abfragesnippets erstellst, die du häufig verwenden wirst. Als Nächstes solltest du nach „gefährlichen“ Metriken suchen und dann andere Tools verwenden, um die Bereinigung zu automatisieren. Der WP-CLI-Befehl wp transient delete kann dir zum Beispiel dabei helfen, unerwünschte Transienten in der Datenbank zu beseitigen.
Von reaktiven Korrekturen zu proaktiver Datenbankwartung
Die Datenbankprobleme, mit denen Agenturen am häufigsten zu tun haben, sind nicht selten oder unvorhersehbar. Sie sind das Ergebnis von bekannten Mustern. Der Unterschied zwischen dem Reagieren auf diese Probleme und dem Vorbeugen liegt auf dem Fokus.
Du musst nicht jede Tabelle untersuchen oder jede Abfrage prüfen. Du musst wissen, welche Teile der Datenbank ständige Aufmerksamkeit verdienen und wie du Frühwarnzeichen erkennst, bevor sie zu Ausfällen oder dringenden Supportanfragen führen.
Für Wartungsagenturen ändert sich dadurch die Art und Weise, wie die Datenbankarbeit in deinen Arbeitsablauf passt. Anstatt die Datenbankbereinigung als einmalige Reparatur zu betrachten, wenn etwas kaputt geht, wird sie zu einer leichten, wiederholbaren Prüfung.
Wenn du auf ein Datenbankproblem stößt, das du nicht lösen kannst, vor allem, wenn es nur unter Last auftritt, ist es wichtig, den richtigen Support zu haben. Für Websites, die bei Kinsta gehostet werden, ist unser Support-Team rund um die Uhr für dich da.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
