Nur die Struktur (Schema) aus einem SQL-Dump exportieren

Drei Situationen kommen immer wieder vor:

• Schema für Staging oder CI aufsetzen — du willst die leere Tabellenstruktur, damit Tests gegen echte Spalten, Indizes und Constraints laufen, aber auf keinen Fall Gigabytes an Produktionsdaten in eine Wegwerf-Umgebung schaufeln.
• Nur Seed-Daten — das Schema existiert in der Zieldatenbank bereits, und du brauchst lediglich die INSERT-Zeilen, um sie zu befüllen, ohne CREATE-Statements, die mit dem Vorhandenen kollidieren würden.
• Ballast loswerden — der Dump ist aufgebläht durch logs-, sessions-, audit_trail- oder cache-Tabellen mit zig Millionen Zeilen, die du nie importieren willst.

Warum mysqldump --no-data nicht ausreicht

Der klassische Rat lautet mysqldump --no-data (nur Struktur) oder mysqldump --no-create-info (nur Daten). Beides sind Export-Flags: Sie ändern, was ein frischer Dump aus einer laufenden Datenbank enthält. Für einen Dump, der bereits als .sql-Datei auf der Platte liegt, tun sie gar nichts.

In der Praxis kommt die Datei oft von jemand anderem, aus einem Backup-Job oder von einem Server, auf den du keinen Live-Zugriff mehr hast. Du kannst mysqldump nicht erneut gegen eine Datenbank laufen lassen, die nicht erreichbar ist — die Zugangsdaten sind weg, der Server ist abgeschaltet, oder die Datei ist schlicht alles, was du bekommen hast. Ab da nützen die Flags nichts, und du bearbeitest die Datei selbst.

Der manuelle Weg

Der naheliegende Schritt ist, Zeilen mit grep oder sed zu entfernen. Um die Struktur zu behalten und die Daten wegzuwerfen:

# alles außer INSERT-Zeilen behalten
grep -v '^INSERT INTO' dump.sql > schema.sql

# oder nur die INSERT-Zeilen für einen reinen Daten-Dump
grep '^INSERT INTO' dump.sql > data.sql

Bei einem kleinen, ordentlichen Dump sieht das gut aus — und bricht dann bei einem echten:

• Mehrzeilige INSERTs. Ein einzelnes INSERT INTO … VALUES kann sich über Tausende Zeilen ziehen. grep trifft die erste Zeile und lässt den Rest der Werte verwaist zurück — die Datei ist kaputt.
• Extended Inserts. mysqldump bündelt viele Zeilen in ein riesiges Statement. Zeilenbasierte Filter erkennen nicht, wo ein solches Statement endet.
• Kommentare und Blöcke. Bedingte /*! … */-Blöcke, LOCK TABLES und -- -Kommentare stehen zwischen den Daten, sodass ein naiver Filter entweder Müll behält oder etwas herausschneidet, das der Import braucht.
• Nur Daten ist noch schlimmer. Ein reines grep '^INSERT' wirft die SET- und LOCK-Statements weg, von denen die Zeilen abhängen, und jedes INSERT, das nicht exakt an Spalte null beginnt, verschwindet stillschweigend.

Am Ende debuggst du deinen eigenen Filter, statt dein Schema zu bekommen.

Nur Struktur oder nur Daten mit DumpCleaner

DumpCleaner versteht SQL-Statements, statt Zeilen zu matchen, und trennt Struktur von Daten zuverlässig — bei Dateien jeder Größe:

1. Zieh deinen .sql-Dump in DumpCleaner (MySQL, MariaDB oder PostgreSQL). Die Datei wird streamend geparst, sodass auch ein mehrere Gigabyte großer Dump mit konstantem Speicher lädt.
2. Schalte die Statement-Typen um, die du willst: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Wähle INSERT INTO ab, und du erhältst nur Struktur; wähle CREATE TABLE / CREATE INDEX ab, und du erhältst nur Daten.
3. Oder nutze ein Preset — Nur Struktur oder Nur Daten — um alle Schalter in einem Schritt zu setzen, und verfeinere danach bei Bedarf pro Tabelle.
4. Exportieren. Du erhältst eine schlanke Schema-Datei für Staging oder CI oder einen sauberen Daten-Dump zum Befüllen.

Weil der Filter statement-aware ist, wird ein mehrzeiliges Extended-INSERT als Ganzes behalten oder verworfen — nie mittendrin zerschnitten.

Die eigentliche Stärke: Das Filtern funktioniert pro Statement-Typ und pro Tabelle, und beides lässt sich kombinieren. Du kannst die Struktur jeder Tabelle behalten, aber INSERT-Daten nur für die drei Tabellen übernehmen, die du wirklich brauchst — und die logs-Tabelle mit 89 Millionen Zeilen als leere Hülle stehen lassen. Das kann kein --no-data-Flag ausdrücken.

Häufige Fragen