WordPress Datenbank aufräumen [Update]

Posted on by

Weil ich gerade wieder akute Probleme mit der SQL-Datenbank habe (Artikel aufrufen und so Zeugs) und mir eine Lösung überlegen musste, habe ich mal ein wenig das Netz durchforstet, was man gegen eine zu fette WordPress Datenbank tun kann.

Meine wp-posts Tabelle ist war unglaubliche 72 Megabyte groß. Eigentlich schon viel zu fett, um sie überhaupt noch sichern zu können. Warum die so riesig ist, liegt nicht zuletzt an den vielen Artikel die es hier gibt (3257 an der Zahl), sondern vielmehr auch an den Revisionen die bei jedem Speichern angelegt werden. Eine Revision ist dafür da, verschiedene Versionen eines Artikels zu haben und dort wieder hin wechseln zu können, sie werden automatisch angelegt und es gibt keine Begrenzung. Wenn einem mal der Browser abstürzt, ist das natürlich recht sinnvoll weil man den Artikel durch die Revision wieder holen kann oder ganz simpel, um Änderungen an dem Artikel nachvollziehen zu können. Aber was ist mit Artikeln von vor nem Jahr, die quasi 20 mal in der Datenbank liegen. Die Datenbank hat sich dadurch bei mir sozusagen verachtfacht.

Lösungswege:

  1. Die WordPress-Datenbank sichern ist der wichtigste Schritt, denn man weiß ja nie, was passieren kann wenn man “am Herzen operiert”.
  2. Man kann in der wp-config.php eine Beschränkung einstellen, wie viele Revisionen zukünftig pro Artikel gespeichert werden. Diese habe ich auf 1 eingestellt. Fügt einfach folgende Zeile zu eurer wp-config.php hinzu:
    ?View Code LANGUAGE
    define('WP_POST_REVISIONS', 1);
  3. Nun wird zukünftig nur noch eine Revision pro Artikel gespeichert. Was aber tut man mit all den alten Revisionen? Man löscht sie einfach per SQL-Befehl. Dazu loggt man sich in seinem phpMyAdmin ein, welches bei vielen Hostern zur Verwaltung der Datenbank dient und gibt dort unter dem Punkt “SQL” folgenden Befehl ein:
    ?View Code LANGUAGE
    DELETE FROM  wp_posts WHERE  post_type = "revision";

    Dies sorgt nun dafür, das die wp-posts nach Revisionen durchsucht wird und diese gelöscht werden. Auswirkungen auf die Artikel selbst hat es natürlich nicht. Nur auf lästigen Ballast.

  4. Am Schluss führen wir noch einen SQL-Befehl aus, welcher die geleerte wp-posts aufräumt und optimiert.
    ?View Code LANGUAGE
    OPTIMIZE TABLE  wp_posts;

    Das wars auch schon. Die Datenbank sollte erheblich entschlackt worden sein und eventuell merkt man das auch in der Geschwindigkeit, wie das Weblog oder WordPress nun agiert.

Meine wp-posts Tabelle ist von 72 MB auf unglaubliche 15 MB geschrumpft. Hammer, oder?

[Update] Mario hat mich darauf hingewiesen, dass es mit diesem Weg zu einer inkonsistenten Datenbank kommen kann

Leider hast Du danach aber eine leidlich inkonsistente Datenbank, da der ganze Schutt in wp_postmeta, der über die post_id mit der ursprünglichen, nun gelöschten, Revision verknüpft war, noch da ist…

Und auch wp_term_relationships, verknüpft über object_id, sollte berücksichtigt werden.

Aber klug wie er ist, hat er auch gleich eine Möglichkeit genannt, wie man das Problem beheben kann. Natürlich ausschließlich auf eigene Gefahr. Ich habe das soeben selbst verifiziert und es hat problemlos funktioniert.

?View Code LANGUAGE
delete meta
from wp_postmeta as meta
left join wp_posts as post
on (post.id = meta.post_id)
where post.id is null

Und dann noch folgenden Befehl einfach kopieren und wie oben schon beschrieben, ausführen.

?View Code LANGUAGE
delete termrel
from wp_term_relationships as termrel
left join wp_posts as post
on (post.id = termrel.object_id)
where post.id is null

So sah das dann bei mir aus:


Das wars nun aber wirklich :-)

HINWEIS: Bitte beachten Sie den folgenden Kommentar, inwiefern er generell gilt und maßgeblich ist, kann ich allerdings nicht verifizieren.

[Update] Der Mainboarder hat auf seiner Website ein Script erstellt, welches man monatlich per Cronjob laufen lassen kann. Man muss hier lediglich eine php Datei auf seinem Webserver anlegen, das Script hinein kopieren, oben die Daten seiner eigenen Email, Datenbank sowie Passwort ändern und das wars auch schon. Bei mir funktioniert das noch immer absolut problemlos, Dank an Mainboarder.

Quelle: yourinspirationweb.com

14 thoughts on “WordPress Datenbank aufräumen [Update]”

  1. Leider hast Du danach aber eine leidlich inkonsistente Datenbank, da der ganze Schutt in wp_postmeta, der über die post_id mit der ursprünglichen, nun gelöschten, Revision verknüpft war, noch da ist…

    Und auch wp_term_relationships, verknüpft über object_id, sollte berücksichtigt werden.

    ciao, Mario

  2. Hmmm.


    delete meta
    from wp_postmeta as meta
    left join wp_posts as post
    on (post.id = meta.post_id)
    where post.id is null

    und


    delete termrel
    from wp_term_relationships as termrel
    left join wp_posts as post
    on (post.id = termrel.object_id)
    where post.id is null

    könnten die Lösung sein.

    Natürlich ohne Gewähr und nur mit Backup usw… ;-)

    • Hey wie geil, Du hast es eben total drauf! Ich werde es natürlich gleich versuchen, aber wenn du den Kommentar nicht mehr lesen kannst, hats nicht geklappt ^^

      Nur davon gehe ich nicht aus :-)

      Danke, Jan.

  3. Schön, dass es funktioniert hat.

    Dann kann ich das bei mir auf den Blogs ja auch mal wagen… ;-)

  4. Danke Ihr Beiden, hab es mit eurer Hilfe jetzt auch mal gewagt und hat problemlos geklappt!

    Kleiner Tipp noch, die beiden Tabellen sollte man, falls was gelöscht wurde, auch noch optimieren:

    OPTIMIZE TABLE wp_postmeta;
    OPTIMIZE TABLE wp_term_relationships;

    Ciao, elmex

  6. Ich hab das ganze auch gemacht, aber:
    Bei den meisten Links waren danach die Verknüpfungen mit den Kategorien gelöscht! Die musste ich im Dashbard wieder herstellen.

    • Oh, solch ein Problem konnte ich bei mir nicht erkennen. Vielleicht liegt es an der neuen Version von WordPress? Ich werde Deinen Hinweis in den Artikel übernehmen.

  7. Ich habe auf die Art und Weise auch meine Post Tabelle erleichtern können ;)
    Das bei dem Löschvorgang die Kategorien gelöscht werden stimmt nicht, hab es mit WP 3.0.4 gemacht und es hat auch nichts mit der WordPress Version an sich zutun! Da es sich hierbei nur um MYSQL Handelt und dem ist WP oder egal was es, ist egal.

    Ich könnte mir Andrews Fehler nur so erklären,das er vielleicht was falsches eingegeben hat?

    Wie immer gilt auch hier,vorher ein Backup anlegen.

      • Keine Ursache^^
        Noch eine kleine Anmerkung meinerseits: Beim eingeben der Befehle die Tabellennamen in “ setzen und keine doppelten Anführungszeichen benutzen, nur einfache ( ‘ ‘ ). Sonst kann es sein, das man sich danach über Fehlermeldungen wundert.

        Und wenn wir grade noch beim Thema Datenbank aufräumen sind, dann sollte man auch die wp_options von Zeit zu Zeit entmüllen. Das geht am besten mit dem folgenden Plugin: klick- Damit lassen sich schnell verweiste Tabelleneinträge ermitteln, aber man sollte vorher sorgfältig prüfen,was man nicht mehr braucht.

        Die wp_options war neben wp_posts die zweitgrößte Tabelle bei mir. Durch das löschen von einigen nicht mehr relevanten Einträgen hab ich gut 2/3 sparen können.

        Auch wenn WordPress durchaus gut ist, hat es doch seine Schattenseiten, im Bezug auf Datenbankoptimierung, Einfachheit der Einstellungen und Allgemein Speicherverbrauch. Wartet dieses CMS mit viele Funktionen auf, fehlt meiner Auffassung die Häfte, die für den Anwender sichtbar ist. Also muss man immer wieder in den WP Codex schauen und nach bestimmten Einstellungen suchen,die man dann meist per wp_config abschalten kann/muss.

        Gerade im Punkt Revisions sollte WordPress nachlegen und diese Funktion sinnvoller einsetzen und nicht auf Benutzer mit großer Datenbanken setzen.