{"id":13634,"date":"2026-10-24T12:45:00","date_gmt":"2026-10-24T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13634"},"modified":"2026-10-24T06:36:05","modified_gmt":"2026-10-24T04:36:05","slug":"2-483-revisionen-auf-926-beitrage-was-in-einer-wordpress-datenbank-wirklich","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/2-483-revisionen-auf-926-beitrage-was-in-einer-wordpress-datenbank-wirklich\/","title":{"rendered":"WordPress-Revisionen: Speicherbedarf, Grenzen und verl\u00e4ssliche Messung"},"content":{"rendered":"

Revisionen speichern fr\u00fchere Bearbeitungsst\u00e4nde in WordPress. Das erleichtert den Vergleich und die Wiederherstellung von Texten, vergr\u00f6\u00dfert aber auch den Datenbestand. Eine gro\u00dfe Zahl von Revisionen beweist weder einen Defekt noch eine langsame Website.<\/p>\n

Eine schreibgesch\u00fctzte Messung dieser Website am 24. Oktober 2026 um 04:19 UTC<\/strong> ergab 7.635 Revisionen in insgesamt 12.284 Zeilen der Beitragstabelle. Rund 79,4 Prozent der dort gespeicherten Inhaltstext-Bytes entfielen auf Revisionen. Diese Momentaufnahme ersetzt die fr\u00fcheren, inzwischen \u00fcberholten Zahlen.<\/p>\n

\"Revisionszeilen
Messung vom 24. Oktober 2026, 04:19 UTC: 7.635 Revisionen; 79,4 % der post_content-Bytes. Keine Messung von Plattenplatz oder Geschwindigkeit.<\/figcaption><\/figure>\n

Was WordPress tats\u00e4chlich speichert<\/h2>\n

Eine Revision enth\u00e4lt standardm\u00e4\u00dfig Titel, Inhalt und Kurztext. WordPress speichert dabei den aktuellen Bearbeitungsstand als eigene, mit dem Beitrag verkn\u00fcpfte Zeile. Nach weiteren \u00c4nderungen wird daraus ein \u00e4lterer Stand. Entsprechend registrierte Metadaten k\u00f6nnen ebenfalls an Revisionen teilnehmen. Eine Revision ist trotzdem keine vollst\u00e4ndige Sicherung aller Beitragseigenschaften oder der Website.<\/p>\n

Nicht jeder Speichervorgang erzeugt eine neue Revision: Der Beitragstyp muss Revisionen unterst\u00fctzen, Revisionen m\u00fcssen aktiviert sein und die relevanten Felder m\u00fcssen sich normalerweise ge\u00e4ndert haben. Filter k\u00f6nnen dieses Verhalten beeinflussen. Ein Skript mit 300 bearbeiteten Beitr\u00e4gen erzeugt deshalb nicht zwangsl\u00e4ufig 300 Revisionen. Direkte SQL-\u00c4nderungen umgehen die \u00fcblichen WordPress-Abl\u00e4ufe vollst\u00e4ndig.<\/p>\n

Automatische Zwischenspeicherungen funktionieren anders: WordPress verwaltet einen Autosave je Beitrag und Benutzer. Ein vorhandener Autosave wird aktualisiert; bei \u00dcbereinstimmung mit dem gespeicherten Beitrag kann der Autosave entfallen.<\/p>\n

Zeilen z\u00e4hlen statt Sch\u00e4tzwerte vergleichen<\/h2>\n

Die untersuchte Tabelle verwendet InnoDB. F\u00fcr diesen Speichermotor kann information_schema.TABLES.TABLE_ROWS<\/code> eine Sch\u00e4tzung liefern. W\u00e4hrend der Messung zeigte die \u00dcbersicht 10.649 Zeilen, die direkte Z\u00e4hlung dagegen 12.284. Das ist kein Beleg f\u00fcr verlorene Datens\u00e4tze.<\/p>\n

Die direkte Z\u00e4hlung ergab 7.635 Revisionen, 2.958 Anh\u00e4nge, 1.689 Beitr\u00e4ge und Seiten sowie zwei weitere Datens\u00e4tze f\u00fcr globale Stile und Navigation. Die 1.689 Beitr\u00e4ge und Seiten umfassen s\u00e4mtliche Statuswerte, darunter Entw\u00fcrfe, geplante Beitr\u00e4ge und Papierkorb. Tats\u00e4chlich ver\u00f6ffentlicht waren 1.290 Beitr\u00e4ge und Seiten. Ein Anhangsdatensatz entspricht zudem nicht jeder automatisch erzeugten Bilddatei.<\/p>\n

\n\"Symbolischer
\n<\/figure>\n

Textmenge ist nicht Dateigr\u00f6\u00dfe<\/h2>\n

Mit OCTET_LENGTH(post_content)<\/code> wurden 92.563.135 Byte in Revisionen und 23.963.672 Byte in Beitr\u00e4gen und Seiten gemessen: rund 88,3 beziehungsweise 22,9 MiB. Ein MiB entspricht 1.048.576 Byte. Die zwei \u00fcbrigen Datens\u00e4tze enthielten zusammen weitere 74 Byte; die Anh\u00e4nge hatten in dieser Messung leere Inhaltstexte. Anh\u00e4nge k\u00f6nnen grunds\u00e4tzlich Beschreibungen enthalten.<\/p>\n

Die Abfrage misst ausschlie\u00dflich die Spalte post_content<\/code>. Titel, andere Spalten, Metadaten, Indizes und bereits reservierter Tabellenplatz fehlen. Aus 88,3 MiB Revisionstext folgen daher weder 88,3 MiB freigebbarer Festplattenplatz noch eine gleich gro\u00dfe Verringerung komprimierter Sicherungen.<\/p>\n

Welche Kosten daraus folgen<\/h2>\n

\u00dcbliche \u00f6ffentliche Beitragsabfragen schlie\u00dfen Revisionen aus. Daraus folgt keine Garantie identischer Ladezeiten mit oder ohne Revisionen: Abfragen, Indizes, Caches, Erweiterungen und Verwaltungsansichten k\u00f6nnen sich unterschiedlich verhalten. Diese Pr\u00fcfung enth\u00e4lt keinen Vergleichstest der Ladegeschwindigkeit.<\/p>\n

Zus\u00e4tzliche Datens\u00e4tze erh\u00f6hen den Umfang logischer Datenbankexporte. Die Auswirkungen auf Sicherungsdauer und \u00dcbertragung h\u00e4ngen jedoch unter anderem von Kompression, Datentr\u00e4gern und Exportverfahren ab. Dreimal so viel Inhalt bedeutet nicht automatisch dreimal so lange Kopierzeit.<\/p>\n

Aufbewahrung gezielt begrenzen<\/h2>\n

WP_POST_REVISIONS<\/code> steuert die regul\u00e4re Aufbewahrung: true<\/code> oder -1<\/code> bedeutet unbegrenzt, eine positive Zahl begrenzt die Revisionen je Beitrag, false<\/code> oder 0<\/code> deaktiviert regul\u00e4re Revisionen. Autosaves bleiben davon ausgenommen. Die gepr\u00fcfte Installation verwendete true<\/code>. WordPress-Filter k\u00f6nnen die wirksame Grenze ver\u00e4ndern.<\/p>\n

Eine passende Grenze h\u00e4ngt vom Bearbeitungsrhythmus und der ben\u00f6tigten R\u00fccksprungtiefe ab. Drei bis f\u00fcnf Fassungen sind keine allgemeing\u00fcltige Empfehlung. Vor umfangreichen \u00c4nderungen erg\u00e4nzen eine gepr\u00fcfte Sicherung und ein nachvollziehbares \u00c4nderungsprotokoll die Revisionen.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

R\u00e4umt eine neue Grenze sofort alle alten Revisionen auf?<\/h3>\n

Nein. Die normale Bereinigung erfolgt beitragsweise im Ablauf einer neu angelegten Revision. Ein blo\u00dfer Konfigurationswechsel oder unver\u00e4ndertes Speichern bereinigt nicht automatisch den gesamten Bestand. Das Abschalten regul\u00e4rer Revisionen l\u00f6scht bestehende Revisionen ebenfalls nicht.<\/p>\n

Warum nicht direkt aus der Beitragstabelle l\u00f6schen?<\/h3>\n

Ein einzelnes SQL-DELETE kann zugeh\u00f6rige Metadaten und Cache-Eintr\u00e4ge zur\u00fccklassen. Die WordPress-Funktion wp_delete_post_revision()<\/code> verwendet den regul\u00e4ren L\u00f6schablauf einschlie\u00dflich der zugeh\u00f6rigen Bereinigung. Eine Bestandsbereinigung ben\u00f6tigt eine gepr\u00fcfte Sicherung und eine ausdr\u00fccklich festgelegte Auswahl. Bei dieser Messung wurden keine Revisionen gel\u00f6scht.<\/p>\n

Wird die Tabellendatei nach dem L\u00f6schen kleiner?<\/h3>\n

Nicht zwangsl\u00e4ufig. InnoDB kann freigegebenen Platz intern wiederverwenden. Ob ein Neuaufbau Platz an das Dateisystem zur\u00fcckgibt, h\u00e4ngt unter anderem von Tablespace und Konfiguration ab. Ein Neuaufbau kann zus\u00e4tzlichen Platz und Wartungszeit ben\u00f6tigen; ein pauschaler OPTIMIZE-TABLE-Befehl folgt daraus nicht.<\/p>\n

Welche Abfrage zeigt die Verteilung?<\/h3>\n

Die folgende reine Leseabfrage trennt Beitragstyp und Status. Das Pr\u00e4fix wp_<\/code> muss dem tats\u00e4chlichen Tabellenpr\u00e4fix entsprechen.<\/p>\n

SELECT post_type, post_status,\n       COUNT(*) AS row_count,\n       COALESCE(SUM(OCTET_LENGTH(post_content)), 0) AS content_bytes\nFROM wp_posts\nGROUP BY post_type, post_status\nORDER BY post_type, post_status;<\/code><\/pre>\n
Die Bytezahl betrifft nur den Inhaltstext. Bei laufender Bearbeitung k\u00f6nnen aufeinanderfolgende Abfragen unterschiedliche Momentaufnahmen liefern.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n