Große SQL-Dump-Datei auf dem Mac öffnen (ohne Absturz)

Ein Dump aus einer Produktionsdatenbank erreicht schnell mehrere zehn Gigabyte. In dem Moment, in dem du ihn in einem normalen Texteditor öffnen willst, dreht der Lüfter auf, der Beachball erscheint, und irgendwann beendet sich die App — manchmal reißt sie ungespeicherte Arbeit in anderen Fenstern mit.

Warum Editoren an großen Dumps scheitern

VS Code, TextEdit, Sublime Text und Co. sind darauf ausgelegt, die komplette Datei in den Arbeitsspeicher zu laden, um sofort scrollen, suchen und hervorheben zu können. Bei einer 2 MB großen Quelldatei ist das kein Problem. Bei einem 40-GB-Dump versucht der Editor, 40 GB (plus Overhead für seine internen Datenstrukturen) im RAM zu belegen.

Dein Mac hat 16 oder 32 GB. Lange bevor die Datei vollständig geladen ist, geht der physische Speicher aus, das System beginnt auf die Festplatte auszulagern und kommt zum Stillstand. Die meisten Editoren verweigern den Dienst ohnehin: VS Code begrenzt Dateien für den vollen Editor auf rund 50 MB und schaltet in einen abgespeckten Modus, TextEdit hängt sich einfach auf, und Sublime belegt Speicher bis zum Absturz. Selbst wenn du die Datei geöffnet bekommst, durchsuchen Syntaxhervorhebung und Suche bei jedem Tastendruck erneut Gigabyte.

Das Kernproblem: Diese Werkzeuge setzen wahlfreien Zugriff auf das ganze Dokument voraus. Ein Dump braucht das gar nicht — er ist eine sequenzielle Liste von Statements. Du musst nur durchstreamen.

Der Weg über die Kommandozeile

Die Unix-Werkzeuge auf deinem Mac streamen bereits und laden nie die ganze Datei. Sie sind der klassische erste Griff:

# Erste und letzte Zeilen anschauen, ohne die ganze Datei zu öffnen
head -n 50 dump.sql
tail -n 50 dump.sql

# Den Dump in 100-MB-Stücke part_aa, part_ab, ... aufteilen
split -b 100m dump.sql part_

# Den Block einer Tabelle zwischen zwei Markern herausziehen
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

Das funktioniert, ist aber fehleranfällig und mühsam. split -b schneidet an rohen Byte-Grenzen, also mitten durch ein INSERT-Statement — die entstehenden Stücke sind für sich genommen kein gültiges SQL. Der sed-Bereichstrick hängt von den exakten Markern ab, die ein bestimmtes Dump-Tool zufällig ausgibt; ändere die MySQL-Version oder wechsle zu PostgreSQL, und das Muster passt nicht mehr. Und nichts davon zeigt dir, was tatsächlich in der Datei steckt — du rätst, welche Tabelle die 30-GB-Tabelle ist, bevor du sie überhaupt ansprechen kannst.

Öffnen und filtern mit DumpCleaner

DumpCleaner ist genau für diese Dateigröße gebaut. Es streamt den Dump wie die Kommandozeile, versteht aber die SQL-Struktur — du bekommst also eine echte Tabellenliste und eine sichere, statement-genaue Ausgabe:

1. Datei hineinziehen. DumpCleaner öffnet den Dump per Streaming in Chunks von rund 1 MB — eine 50-GB-Datei öffnet mit etwa 50 MB RAM, nichts friert ein.
2. Jede Tabelle sehen. Es scannt den Dump und listet jede Tabelle mit ihrer Größe, sodass du sofort erkennst, welche die Datei aufbläht.
3. Nicht Benötigtes abwählen. Hake die riesigen Log-, Session- oder Analytics-Tabellen ab. DumpCleaner hält ganze Statements intakt — keine halb abgeschnittenen INSERTs.
4. Exportieren. Schreibe eine neue, kleinere .sql-Datei, die sich endlich bequem öffnen und importieren lässt. Deine Originaldatei wird nie verändert.

Weil es 50 GB und größere Dumps mit konstantem Speicher verarbeitet, musst du dir über den RAM deines Macs keine Gedanken machen. Und da es die Quelle liest und eine separate Ausgabe schreibt, bleibt der Dump, mit dem du gestartet bist, genau so, wie er war.

Häufige Fragen