{"id":516,"date":"2026-09-30T13:25:00","date_gmt":"2026-09-30T11:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?page_id=516"},"modified":"2026-09-25T15:07:51","modified_gmt":"2026-09-25T13:07:51","slug":"automatisiertes-datenbank-cleaning-via-wp-cli-und-server-cronjob","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/automatisiertes-datenbank-cleaning-via-wp-cli-und-server-cronjob\/","title":{"rendered":"Automatisiertes Datenbank-Cleaning via WP-CLI und Server-Cronjob"},"content":{"rendered":"
Architektur-\u00dcberblick: Datenbank-Fragmentierung in WordPress<\/h2>\n
Mit wachsender Lebensdauer einer WordPress-v7.0.2-Installation unterliegt die zugrundeliegende MySQL- oder MariaDB-Datenbank einer erheblichen Fragmentierung und Datenbl\u00e4hung. Jedes redaktionelle Speichern erzeugt einen neuen Eintrag in der Tabelle wp_posts<\/code> als Beitragsrevision. Gleichzeitig schreiben Plugins und Themes regelm\u00e4\u00dfig tempor\u00e4re Cache-Daten als sogenannte Transients in die Tabelle wp_options<\/code>. Nach Ablauf der G\u00fcltigkeit l\u00f6scht WordPress diese Transients standardm\u00e4\u00dfig tr\u00e4ge w\u00e4hrend regul\u00e4rer HTTP-Anfragen, wodurch oft Tausende veralteter Zeilen verbleiben.<\/p>\n
Dar\u00fcber hinaus hinterl\u00e4sst das L\u00f6schen von Artikeln oder Custom Post Types ohne explizite Bereinigungsroutinen verwaiste Metadaten in der Tabelle wp_postmeta<\/code>. Diese unkontrollierte Ansammlung vergr\u00f6\u00dfert die Datenbank-Indizes, verlangsamt die Ausf\u00fchrungszeit komplexer SELECT<\/code>-Abfragen und erh\u00f6ht den Arbeitsspeicherbedarf des Datenbankservers. Eine automatisierte Bereinigung \u00fcber WP-CLI und Server-Cronjobs umgeht den Webserver-Stack vollst\u00e4ndig und sorgt f\u00fcr eine hochperformante, blockierungsfreie Wartung ohne PHP-Laufzeitbegrenzungen.<\/p>\n\nVier Sorten Ballast machen den Gro\u00dfteil einer gewachsenen WordPress-Datenbank aus. Das w\u00f6chentliche Skript r\u00e4umt sie in fester Reihenfolge ab und defragmentiert danach \u2014 \u00fcbrig bleibt der Inhalt, der wirklich ausgeliefert wird.<\/figcaption><\/figure>\n
Schritt 1: Analyse der Datenbank-Gr\u00f6\u00dfe und CLI-Audit<\/h3>\n
Vor der Ausf\u00fchrung von L\u00f6schroutinen sollte die aktuelle Gr\u00f6\u00dfe und Struktur der Datenbank \u00fcber eine SSH-Verbindung mittels WP-CLI analysiert werden. Der folgende Befehl listet alle Tabellen absteigend nach ihrer Speichergr\u00f6\u00dfe in Megabyte auf:<\/p>\n
wp db size --tables --human-readable<\/code><\/pre>\n
Um die genaue Anzahl der aktuell in der Options-Tabelle verbliebenen, abgelaufenen Transients zu ermitteln, kann eine erste Diagnoseabfrage ausgef\u00fchrt werden:<\/p>\n
wp db query \"SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();\"<\/code><\/pre>\n
Schritt 2: Entwicklung des automatisierten Wartungs-Skripts<\/h3>\n
Um veraltete Daten sicher zu eliminieren, ohne auf Ressourcen verbrauchende Drittanbieter-Plugins angewiesen zu sein, eignet sich ein dediziertes Shell-Skript auf Basis von WP-CLI und direkten SQL-Befehlen. Das Skript adressiert vier Hauptursachen f\u00fcr Datenbank-Bloat:<\/p>\n
\n
Abgelaufene Transients:<\/strong> Entfernt alle ung\u00fcltigen Cache-Eintr\u00e4ge aus wp_options<\/code>.<\/li>\n
Veraltete Beitragsrevisionen:<\/strong> Bereinigt historische Revisions-Objekte aus wp_posts<\/code>.<\/li>\n
Verwaiste Postmeta-Eintr\u00e4ge:<\/strong> F\u00fchrt eine relationale DELETE<\/code>-Abfrage aus, um Metadaten zu l\u00f6schen, deren \u00fcbergeordneter Post-ID-Eintrag nicht mehr existiert.<\/li>\n
Verwaiste Taxonomie-Verkn\u00fcpfungen:<\/strong> Entfernt Zuordnungen in wp_term_relationships<\/code>, deren zugeh\u00f6riger Beitrag nicht mehr existiert. Mit Polylang oder mit Taxonomien f\u00fcr andere Objekttypen l\u00f6scht die Abfrage auch Zuordnungen, die gar keinem Beitrag gelten, etwa die Sprachzuordnungen der Rubriken und Schlagw\u00f6rter; N\u00e4heres unter \u201eFragen und Antworten\u201c.<\/li>\n<\/ul>\n
Das folgende produktionsreife Skript kann auf dem Server unter \/opt\/scripts\/wp-db-cleanup.sh<\/code> abgelegt werden:<\/p>\n
#!\/usr\/bin\/env bash\n# ============================================================================\n# Hochperformantes WordPress-Datenbank-Bereinigungsskript\n# Zielsystem: WordPress v7.0.2 via WP-CLI\n# ============================================================================\n\nWP_PATH=\"\/var\/www\/lukaswojcik.com\/htdocs\"\nLOG_FILE=\"\/var\/log\/wp_db_cleanup.log\"\n\necho \"[$(date +'%Y-%m-%d %H:%M:%S')] Wartungszyklus gestartet...\" >> \"$LOG_FILE\"\n\n# 1. Alle abgelaufenen Transients l\u00f6schen\nwp transient delete --expired --path=\"$WP_PATH\" >> \"$LOG_FILE\" 2>&1\n\n# 2. Alle Beitragsrevisionen l\u00f6schen (optional: Limitierung auf die letzten 3)\nREVISIONS=$(wp post list --post_type=revision --format=ids --path=\"$WP_PATH\")\nif [ -n \"$REVISIONS\" ]; then\n wp post delete $REVISIONS --force --path=\"$WP_PATH\" >> \"$LOG_FILE\" 2>&1\nfi\n\n# 3. Verwaiste Postmeta-Eintr\u00e4ge via direkte relationale SQL-Abfrage l\u00f6schen\nwp db query \"DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;\" --path=\"$WP_PATH\" >> \"$LOG_FILE\" 2>&1\n\n# 4. Verwaiste Taxonomie-Verkn\u00fcpfungen entfernen\n# Achtung: l\u00f6scht mit Polylang auch Sprachzuordnungen von Termen (object_id = Term-ID)\nwp db query \"DELETE tr FROM wp_term_relationships tr LEFT JOIN wp_posts wp ON wp.ID = tr.object_id WHERE wp.ID IS NULL;\" --path=\"$WP_PATH\" >> \"$LOG_FILE\" 2>&1\n\n# 5. MySQL\/MariaDB-Speicher-Engines defragmentieren und optimieren\nwp db optimize --path=\"$WP_PATH\" >> \"$LOG_FILE\" 2>&1\n\necho \"[$(date +'%Y-%m-%d %H:%M:%S')] Wartungszyklus erfolgreich beendet.\" >> \"$LOG_FILE\"<\/code><\/pre>\n
Um unbefugte Ausf\u00fchrungen zu verhindern, m\u00fcssen dem Shell-Skript restriktive Unix-Dateirechte zugewiesen werden. Die Ausf\u00fchrung sollte ausschlie\u00dflich dem Administrations-Benutzer oder dem Systemkonto des Webservers gestattet sein:<\/p>\n
Im Gegensatz zum standardm\u00e4\u00dfigen WP-Cron, der auf eingehenden HTTP-Verkehr angewiesen ist und auf Seiten mit geringem Traffic verz\u00f6gert ausl\u00f6sen kann, garantiert ein nativer Linux-Cronjob die Ausf\u00fchrung zu pr\u00e4zisen Zeitpunkten. Um die Bereinigung jeden Sonntag um 03:00 Uhr morgens ausf\u00fchren zu lassen, wird die Crontab-Konfiguration bearbeitet:<\/p>\n
crontab -e -u www-data<\/code><\/pre>\n
Folgende Zeitplan-Zeile wird am Ende der Crontab-Datei hinzugef\u00fcgt:<\/p>\n
Schritt 5: Qualit\u00e4tssicherung und Verifikation<\/h3>\n
Nach einer manuellen Testausf\u00fchrung des Skripts sollte die erfolgreiche Bereinigung \u00fcber Terminal-Befehle verifiziert werden:<\/p>\n
\n
Pr\u00fcfung der Logfiles:<\/strong> Kontrolle der Datei `\/var\/log\/wp_db_cleanup.log` auf Abwesenheit von Syntax-Fehlern oder Datenbank-Locks.<\/li>\n
Validierung der Tabellen-Optimierung:<\/strong> Ausf\u00fchrung von `wp db size –human-readable` zur Best\u00e4tigung des reduzierten Speicherbedarfs von `wp_postmeta` und `wp_posts`.<\/li>\n
Integrit\u00e4tspr\u00fcfung im Frontend:<\/strong> Sicherstellen, dass aktive Artikel, eigene Toolbox-Skripte und Polylang-Sprachbeziehungen fehlerfrei und ohne fehlende Metadaten geladen werden.<\/li>\n<\/ol>\n
Zusammenfassung und resultierender Mehrwert<\/h2>\n
Was sich damit erreichen l\u00e4sst:<\/strong> Der vollst\u00e4ndige Verzicht auf manuelle Datenbankbereinigungen und ressourcenintensive Optimierungs-Plugins zugunsten einer autonomen, auf Serverebene operierenden Wartungs-Pipeline mittels WP-CLI und Linux-Cronjobs.<\/p>\n
Resultierender Mehrwert:<\/strong><\/p>\n
\n
Dauerhaft schlanke Datenbankstruktur:<\/strong> Relationale Tabellen bleiben defragmentiert und frei von verwaisten Metadaten, wodurch die Gesamtgr\u00f6\u00dfe der Datenbank bei aktiven Publikationssystemen um 40\u201360 % sinkt.<\/li>\n
Beschleunigte SQL-Ausf\u00fchrungsgeschwindigkeit:<\/strong> Bereinigte Indizes reduzieren die Ausf\u00fchrungszeit f\u00fcr dynamische Dashboard-Aufrufe und komplexe JOIN-Abfragen signifikant.<\/li>\n
Null PHP-Ressourcenbelastung:<\/strong> Die Ausf\u00fchrung au\u00dferhalb des Webserver-Kontexts verhindert HTTP-Timeouts, Arbeitsspeicherspitzen und Ladezeitverz\u00f6gerungen f\u00fcr Besucher im Frontend.<\/li>\n<\/ul>\n
\n
Fragen und Antworten<\/h2>\n
Warum l\u00e4uft das Skript von Hand fehlerfrei, aus dem Cronjob aber nicht?<\/h3>\n
Meist wegen einer anderen Umgebung. Cron startet Befehle mit einer knappen Umgebung, und drei Unterschiede sind die h\u00e4ufigsten Ursachen:<\/p>\n
\n
Der Suchpfad. Cron setzt PATH in der Regel nur auf \/usr\/bin:\/bin. Liegt WP-CLI, wie oft, unter \/usr\/local\/bin\/wp, findet das Skript den Befehl wp nicht. Abhilfe schafft ein vollst\u00e4ndiger Pfad im Skript oder eine PATH-Zeile am Anfang der Crontab.<\/li>\n
Die Schreibrechte der Logdatei. Das Skript l\u00e4uft als www-data und schreibt nach \/var\/log\/wp_db_cleanup.log, in ein Verzeichnis, das f\u00fcr www-data \u00fcblicherweise nicht beschreibbar ist. Scheitert die Umleitung in die Logdatei, f\u00fchrt die Shell den betreffenden Befehl gar nicht erst aus; die Datenbank bleibt also unber\u00fchrt. Die Datei muss deshalb vorher angelegt und www-data \u00fcbergeben werden, oder das Log liegt an einem Ort, an dem www-data schreiben darf.<\/li>\n
Die verschluckte Ausgabe. Die Crontab-Zeile leitet alles nach \/dev\/null. Die Fehlermeldungen der gescheiterten Umleitungen verschwinden dort, und der Lauf wirkt still erfolgreich.<\/li>\n<\/ol>\n
Ein Probelauf unter denselben Bedingungen zeigt diese Fehler vorab, etwa mit sudo -u www-data env -i PATH=\/usr\/bin:\/bin \/bin\/bash \/opt\/scripts\/wp-db-cleanup.sh<\/code>. L\u00e4uft das Skript so durch, sind die h\u00e4ufigsten Ursachen ausgeschlossen.<\/p>\n
Ist die Abfrage f\u00fcr verwaiste Taxonomie-Verkn\u00fcpfungen auf jeder Installation sicher?<\/h3>\n
Nein. Die Tabelle wp_term_relationships verkn\u00fcpft Terme nicht nur mit Beitr\u00e4gen. Eine Taxonomie kann f\u00fcr andere Objekttypen registriert sein, etwa f\u00fcr Benutzer oder f\u00fcr die alten Links aus wp_links; dann steht in object_id keine Beitrags-ID. Mehrsprachigkeits-Plugins wie Polylang ordnen au\u00dferdem Rubriken und Schlagw\u00f6rter \u00fcber diese Tabelle ihrer Sprache und ihren \u00dcbersetzungen zu, mit der Term-ID als object_id.<\/p>\n
Die Abfrage aus dem Skript l\u00f6scht jede Zeile, deren object_id in wp_posts fehlt, und trifft damit genau diese Zuordnungen. T\u00fcckisch ist, dass sie nicht alle trifft: Eine Term-ID, die zuf\u00e4llig auch als Beitrags-ID existiert, bleibt stehen. Das Ergebnis sind vereinzelte Rubriken ohne Sprache oder ohne \u00dcbersetzung, verstreut und schwer zu erkl\u00e4ren.<\/p>\n
Sicherer ist eine Einschr\u00e4nkung auf die Taxonomien, die tats\u00e4chlich an Beitr\u00e4gen h\u00e4ngen, \u00fcber einen JOIN auf wp_term_taxonomy und eine Liste wie category und post_tag. Vor jedem L\u00f6schlauf ist au\u00dferdem eine Sicherung n\u00f6tig, etwa mit wp db export<\/code>, und ein Probelauf mit SELECT COUNT(*) statt DELETE zeigt, wie viele Zeilen betroffen w\u00e4ren.<\/p>\n
Was bewirkt wp db optimize auf InnoDB-Tabellen?<\/h3>\n
InnoDB kennt kein eigenes Optimieren. MySQL und MariaDB bauen die Tabelle stattdessen neu auf und aktualisieren ihre Statistiken; die Meldung dazu lautet \u201eTable does not support optimize, doing recreate + analyze instead\u201c. F\u00fcr den Neuaufbau braucht der Server vor\u00fcbergehend etwa so viel freien Plattenplatz, wie die Tabelle belegt, und gro\u00dfe Tabellen brauchen entsprechend lange.<\/p>\n
Kleiner wird die Datei nur, wenn jede Tabelle eine eigene Datei hat (innodb_file_per_table, in aktuellen Versionen Standard). Liegen die Tabellen im gemeinsamen Systemtablespace, bleibt dessen Datei gleich gro\u00df. Nach einer gro\u00dfen L\u00f6schaktion lohnt der Neuaufbau; als w\u00f6chentliche Routine bringt er wenig, weil InnoDB frei gewordenen Platz innerhalb der Tabelle ohnehin wiederverwendet.<\/p>\n
L\u00e4sst sich die Zahl der Revisionen begrenzen, statt sie jede Woche vollst\u00e4ndig zu l\u00f6schen?<\/h3>\n
Ja, mit der Konstante WP_POST_REVISIONS in der wp-config.php, etwa define( 'WP_POST_REVISIONS', 3 );<\/code>. WordPress entfernt dann beim n\u00e4chsten Speichern eines Beitrags dessen \u00e4lteste Revisionen \u00fcber die Grenze hinaus. Die Versionsgeschichte bleibt so in begrenztem Umfang erhalten, statt jede Woche vollst\u00e4ndig gel\u00f6scht zu werden.<\/p>\n<\/div>\n
![\"Gestapelter](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/hand-dbputz-de.png\")