OPTIMIZE TABLE gibt nichts frei — was der Overhead-Wert wirklich bedeutet

von Robert Klikics 9 Min Lesezeit veröffentlicht 12. September 2026 zuletzt geändert 1. Oktober 2026

Fast jede Anleitung zum Aufräumen einer WordPress-Datenbank enthält denselben Schritt: Overhead anzeigen lassen, OPTIMIZE TABLE laufen lassen, Platz zurückgewinnen. Die Zahl, auf die sich das stützt, heißt DATA_FREE und steht in information_schema.TABLES.

Diese Zahl bedeutet nicht überall dasselbe. Sie bedeutet je nach Speicher-Engine und je nach einer einzelnen Servereinstellung drei verschiedene Dinge, und in einem der drei Fälle ist sie schlicht nicht additiv. Wer sie über alle Tabellen aufsummiert, bekommt in diesem Fall denselben Wert dreißigmal gezählt.

Was folgt, ist nachgemessen: auf einer eigens dafür angelegten Datenbank, mit den Dateigrößen auf der Platte daneben.

Kurz gefasst

• DATA_FREE bedeutet je nach Speicher-Engine etwas anderes und ist im dritten Fall nicht einmal addierbar.
• Bei MyISAM sagte der Wert den zurückgewonnenen Platz auf das Byte genau voraus: 947.904 Byte gemeldet, 947.904 Byte zurückgegeben.
• Bei InnoDB reagierte er nicht auf das Löschen von 4.900 Zeilen und lag um das Doppelte daneben: 4.194.304 Byte gemeldet, 8.388.608 Byte durch den Neuaufbau zurückgegeben. OPTIMIZE TABLE meldet dort selbst, dass es die Tabelle stattdessen neu aufbaut.
• Mit innodb_file_per_table=OFF meldeten drei Tabellen mit je 16 KB Daten dieselben 133.169.152 Byte als frei — eine Summe darüber zählt denselben Wert mehrfach.
• Gemessen am 22. August 2026 auf MariaDB 10.11.18 mit 16-KB-Seiten.

Drei Bedeutungen einer Zahl

MyISAM: echter Verschnitt

Bei MyISAM beschreibt DATA_FREE Lücken in der Datendatei, die durch gelöschte oder verkürzte Zeilen entstanden sind. Diese Lücken belegen Platz im Dateisystem, und OPTIMIZE TABLE schreibt die Datei neu und gibt sie zurück. Hier stimmt die Erzählung der Ratgeber.

InnoDB mit eigener Datei je Tabelle

Bei InnoDB mit innodb_file_per_table=ON beschreibt DATA_FREE freien Platz innerhalb der Datei, die zu dieser Tabelle gehört. Die Engine verwendet ihn für neue Zeilen wieder. Er ist also nicht verloren, sondern vorgehalten. Ein Neuaufbau kann einen Teil davon ans Dateisystem zurückgeben — oder die Datei sogar vergrößern.

InnoDB im gemeinsamen Tablespace

Steht innodb_file_per_table auf OFF, liegen alle Tabellen in einer gemeinsamen Datei, ibdata1. DATA_FREE beschreibt dann den freien Platz in dieser einen Datei — und jede Tabelle meldet denselben Wert. Der Wert gehört nicht zur Tabelle, neben der er steht.

Das Experiment

Zwei Tabellen mit identischem Aufbau, eine als MyISAM, eine als InnoDB, jeweils mit 9.875 Zeilen zu je 180 Byte Nutzlast gefüllt. Server: MariaDB 10.11.18, innodb_file_per_table=1, Seitengröße 16 KB. Nach jedem Schritt ANALYZE TABLE, damit die Statistik nicht veraltet ist, und ein Blick in das Datenverzeichnis.

Ausgangslage:

Schon hier fällt bei InnoDB etwas auf, das die Ratgeber nie erwähnen: Die Tabelle wurde gerade erst gefüllt, es wurde nichts gelöscht — und trotzdem stehen 4 Megabyte in DATA_FREE. Die Datei ist 10,5 Megabyte groß bei 2,6 Megabyte Daten. InnoDB belegt Platz in Extents, also in Blöcken, und meldet den nicht benutzten Teil davon als frei. Das ist kein Verschnitt, das ist Vorratshaltung.

Jetzt wird in beiden Tabellen jede zweite Zeile gelöscht, rund 4.900 Zeilen:

MyISAM meldet die Lücke sofort und genau: 947.904 Byte, ungefähr die Hälfte der Daten. Die Datei ist unverändert groß, der Platz ist noch belegt.

InnoDB meldet dieselbe Zahl wie vorher. Das Löschen von 4.900 Zeilen hat DATA_FREE nicht bewegt. Wer diesen Wert beobachtet, um zu sehen, ob eine Aufräumaktion etwas gebracht hat, bekommt hier keine Antwort.

Was OPTIMIZE TABLE dann tut

OPTIMIZE TABLE myisam_demo;
Table                    Op         Msg_type  Msg_text
tp_datafree.myisam_demo  optimize   status    OK

OPTIMIZE TABLE innodb_demo;
Table                    Op         Msg_type  Msg_text
tp_datafree.innodb_demo  optimize   note      Table does not support optimize,
                                              doing recreate + analyze instead
tp_datafree.innodb_demo  optimize   status    OK

Der Server sagt es selbst: InnoDB kennt OPTIMIZE TABLE nicht. Der Befehl wird in einen vollständigen Neuaufbau der Tabelle übersetzt. Das ist etwas anderes als das, was der Name verspricht, und es hat andere Kosten — die Tabelle wird kopiert, was Platz und Zeit braucht.

Bei MyISAM sagte DATA_FREE 947.904 Byte voraus, und genau 947.904 Byte kamen zurück. Auf das Byte.

Bei InnoDB sagte DATA_FREE 4.194.304 Byte, zurück kamen 8.388.608 — das Doppelte. Die Zahl war nicht zu hoch, sie war zu niedrig, und sie stand in keinem erkennbaren Verhältnis zum Ergebnis. Sie beschreibt eben nicht, was ein Neuaufbau zurückgibt.

Damit ist die verbreitete Formel „DATA_FREE ist der Platz, den OPTIMIZE TABLE zurückholt“ für die Engine, die praktisch jede WordPress-Installation verwendet, in beide Richtungen falsch.

Der Fall, in dem die Zahl gar nicht zur Tabelle gehört

Für den dritten Fall wurden drei leere InnoDB-Tabellen angelegt, während innodb_file_per_table kurzzeitig auf OFF stand. Die Einstellung wirkt nur auf Tabellen, die währenddessen entstehen; bestehende bleiben, wo sie sind.

TABLE_NAME  ENGINE  DATA_LENGTH  DATA_FREE
shared_a    InnoDB        16384  133169152
shared_b    InnoDB        16384  133169152
shared_c    InnoDB        16384  133169152

Drei Tabellen mit je 16 Kilobyte Daten, und jede meldet 133.169.152 Byte frei — 127 Megabyte. Es ist derselbe Wert, dreimal. Er beschreibt den freien Platz in ibdata1, die auf diesem Server 146.800.640 Byte groß ist. Eigene .ibd-Dateien haben die drei nicht, nur je eine .frm.

Ein Werkzeug, das hier aufsummiert, meldet für eine Datenbank mit 48 Kilobyte Inhalt einen Overhead von 381 Megabyte. Bei dreißig Tabellen wären es vier Gigabyte. Die Zahl wäre nicht ungenau, sie wäre erfunden.

Wie dieser Fehler aussieht, wenn er passiert

Der anschaulichste Beleg dafür ist ein eigener Fehler. Die beiden folgenden Zahlen sind keine aktuelle Messung, sondern stammen aus der Entwicklungsgeschichte von Turbopress Database Diagnostics und sind dort im Commit vom 10. August 2026 festgehalten. Eine frühe Fassung des Plugins summierte DATA_FREE über alle Tabellen, nannte das Ergebnis Overhead, den OPTIMIZE TABLE zurückholen würde, und stellte es neben eine Gesamtgröße, die nur Daten und Indizes zählte.

Herausgekommen ist eine Anzeige, die eine Datenbank mit 2,1 Megabyte Größe und 4,0 Megabyte Overhead meldete. Das kann nicht sein, und weil es nicht sein kann, ist es ein brauchbarer Test: Wenn dein Werkzeug mehr Overhead anzeigt als Gesamtgröße, addiert es Werte, die nicht zusammengehören.

Die Korrektur desselben Commits liest @@innodb_file_per_table einmal aus, trennt den freien Platz nach Engine, behält die Aussage „zurückgewinnbar“ nur für MyISAM, lässt den Wert dort ganz weg, wo er nichts über die einzelne Tabelle sagt, und meldet die Größe als Daten plus Indizes plus dem Platz, den die Tabellen tatsächlich belegen. Dieselbe Testdatenbank stand danach — wieder die Zahl von damals, nicht von heute — mit 13,6 Megabyte Daten und Indizes, die 34,6 Megabyte belegen, dazu 21,0 Megabyte freier Platz im InnoDB-Tablespace, getrennt benannt.

Was das für eine echte Installation heißt

Die Datenbank hinter turbopress.de sieht so aus:

Ein Aufräum-Plugin würde daraus „20 MB Overhead, jetzt optimieren“ machen. Nach der Messung oben heißt es: 37 InnoDB-Tabellen halten Extents vor, die sie beim nächsten Wachstum selbst wieder benutzen. Ein Neuaufbau aller Tabellen würde einen Teil davon zurückgeben, einen unbekannten Teil, und dafür jede Tabelle einmal kopieren.

Bei den größten Tabellen wird sichtbar, wie grob die Zahl ist: postmeta belegt 37.264 Kilobyte und meldet 12.288 Kilobyte frei, posts 8.416 Kilobyte und 4.096 Kilobyte frei, options 3.648 Kilobyte und ebenfalls 4.096 Kilobyte frei. Alle drei Werte sind glatte Vielfache von 4 Megabyte. Das ist keine Messung von Verschnitt, das ist die Extent-Verwaltung von InnoDB.

Dass options mehr freien Platz meldet, als die Tabelle groß ist, ist danach kein Widerspruch mehr, sondern die Regel.

Wann ein Neuaufbau trotzdem etwas bringt

Aus alldem folgt nicht, dass ein Neuaufbau bei InnoDB nie lohnt. Im Experiment oben hat er die Datei von 10.485.760 auf 2.097.152 Byte verkleinert, also auf ein Fünftel. Nur war der Anlass ein besonderer: Die Tabelle war frisch gefüllt und danach zur Hälfte geleert worden. Genau diese Konstellation entsteht auch auf echten Installationen — wenn du eine halbe Million verwaister Metazeilen löschst oder eine Protokolltabelle leerst, die jahrelang gewachsen ist.

Die Regel dahinter ist einfacher als jede Overhead-Anzeige: Ein Neuaufbau lohnt nach einer großen, einmaligen Löschaktion, weil die Tabelle den frei gewordenen Platz sonst erst über Monate wieder auffüllt. Er lohnt nicht als wiederkehrende Wartung, weil im Normalbetrieb genau das passiert, wofür InnoDB den Platz vorhält.

Und er ist nicht kostenlos. Der Neuaufbau kopiert die Tabelle. Während er läuft, braucht der Server Platz für beide Fassungen gleichzeitig, und je nach Version und Aufbau der Tabelle blockiert er schreibende Zugriffe. Bei einer postmeta von 37 Megabyte merkt das niemand. Bei einer von vier Gigabyte auf einem Shop schon.

Die Datei ist die ehrlichere Zahl

Wer Zugriff auf den Server hat, umgeht die ganze Deutungsfrage, indem er nachsieht, was die Tabelle tatsächlich belegt. Das Datenverzeichnis steht in @@datadir, darunter liegt je Datenbank ein Verzeichnis und darin je Tabelle eine .ibd-Datei:

SELECT @@datadir;
-- danach auf dem Server, Verzeichnis- und Tabellennamen anpassen:
-- ls -l /var/lib/mysql/DATENBANK/*.ibd

Die Differenz zwischen dieser Dateigröße und DATA_LENGTH + INDEX_LENGTH ist das, was die Tabelle über ihren Inhalt hinaus belegt. Im Experiment waren das vor dem Neuaufbau 7,9 Megabyte, während DATA_FREE 4,0 meldete. Fehlt .ibd ganz und liegt nur eine .frm dort, ist die Tabelle im gemeinsamen Tablespace — und du bist im dritten Fall.

Selbst nachsehen

Zuerst die Einstellung, ohne die der Rest nicht zu deuten ist:

SELECT @@innodb_file_per_table, @@version;

Steht dort 0, ist jede Angabe zu freiem Platz je Tabelle bedeutungslos, und keine Summe darüber ergibt Sinn. Steht dort 1, lohnt der Blick auf die einzelnen Tabellen. Den Datenbanknamen anpassen:

SELECT TABLE_NAME,
       ENGINE,
       TABLE_ROWS,
       ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024) AS kb_belegt,
       ROUND(DATA_FREE / 1024)                    AS kb_data_free
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
ORDER BY DATA_LENGTH + INDEX_LENGTH DESC;

Zu lesen ist das so: In der Spalte ENGINE steht bei fast allen Zeilen InnoDB. Für diese Zeilen ist kb_data_free kein Aufräumauftrag. Steht irgendwo MyISAM — meist bei alten Tabellen ausrangierter Plugins —, dann ist der Wert dort echt, und ein OPTIMIZE TABLE auf genau diese Tabelle gibt genau diesen Platz zurück.

Und wenn du wissen willst, ob eine Aufräumaktion in einer InnoDB-Tabelle etwas gebracht hat, hilft DATA_FREE nicht weiter. Dann zählst du Zeilen, vorher und nachher.

Turbopress Database Diagnostics unterscheidet beim Auslesen die Engines, behält die Aussage über zurückgewinnbaren Platz für MyISAM und lässt den Wert dort weg, wo er über die einzelne Tabelle nichts aussagt.

Was in einer WordPress-Datenbank wirklich Platz kostet und wovon man Zeilen zählen kann, steht hier: WordPress-Datenbank aufräumen. Weitere Messungen aus derselben Reihe sammeln sich unter Wissen.

Welche Datenbank hinter einer WordPress-Installation arbeitet, entscheidet mit darüber, was ein OPTIMIZE TABLE überhaupt bewirken kann. Bei turbopress ist das MariaDB — die übrigen Bausteine stehen im turbopress Tech-Stack.