Comment ouvrir un gros fichier dump SQL sur Mac (sans plantage)

Un dump de base de données de production peut facilement atteindre des dizaines de gigaoctets. Dès que vous tentez de l'ouvrir dans un éditeur de texte classique, le ventilateur de votre Mac s'emballe, la roue multicolore apparaît, et l'application finit par se fermer — emportant parfois du travail non enregistré dans d'autres fenêtres.

Pourquoi les éditeurs s'étouffent sur les gros dumps

VS Code, TextEdit, Sublime Text et consorts sont conçus pour charger le fichier entier en mémoire afin de pouvoir défiler, rechercher et colorer instantanément. C'est parfait pour un fichier source de 2 Mo. Pour un dump de 40 Go, cela signifie que l'éditeur tente d'allouer 40 Go (plus la surcharge de ses structures de données internes) en RAM.

Votre Mac dispose de 16 ou 32 Go. Bien avant que le fichier ne soit entièrement chargé, le système manque de mémoire physique, commence à basculer sur le disque (swap) et s'arrête net. La plupart des éditeurs refusent d'ailleurs carrément : VS Code plafonne les fichiers autour de 50 Mo pour l'éditeur complet et bascule en mode allégé, TextEdit se fige tout simplement, et Sublime alloue jusqu'à planter. Même si vous parvenez à ouvrir le fichier, la coloration syntaxique et la recherche réanalysent des gigaoctets à chaque frappe.

Le problème fondamental : ces outils supposent un accès aléatoire à l'ensemble du document. Un dump n'en a pas besoin — c'est une liste séquentielle d'instructions. Il suffit de le parcourir en flux.

La méthode en ligne de commande

Les outils Unix de votre Mac fonctionnent déjà en flux, si bien qu'ils ne chargent jamais le fichier entier. C'est le premier recours classique :

# Jeter un œil aux premières et dernières lignes sans ouvrir tout le fichier
head -n 50 dump.sql
tail -n 50 dump.sql

# Découper le dump en morceaux de 100 Mo nommés part_aa, part_ab, ...
split -b 100m dump.sql part_

# Extraire le bloc d'une table entre deux marqueurs
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

Cela fonctionne, mais c'est fragile et fastidieux. split -b coupe sur des frontières d'octets brutes, il tranchera donc en plein milieu d'une instruction INSERT — les morceaux obtenus ne sont pas du SQL valide à eux seuls. L'astuce de plage sed dépend des marqueurs exacts qu'un outil de dump précis émet ; changez de version de MySQL ou passez à PostgreSQL et le motif ne correspond plus. Et rien de tout cela ne vous donne une vue de ce qui se trouve réellement dans le fichier — vous devinez quelle table pèse 30 Go avant même de pouvoir la cibler.

Ouvrez-le et filtrez-le avec DumpCleaner

DumpCleaner a été conçu précisément pour cette taille de fichier. Il parcourt le dump en flux comme le fait la ligne de commande, mais il comprend la structure SQL, si bien que vous obtenez une vraie liste de tables et une sortie sûre, consciente des instructions :

1. Glissez le fichier. DumpCleaner ouvre le dump en le parcourant par morceaux d'environ 1 Mo — un fichier de 50 Go s'ouvre avec à peu près 50 Mo de RAM, donc rien ne se fige.
2. Voyez chaque table. Il analyse le dump et liste chaque table avec sa taille, pour repérer immédiatement celle qui fait gonfler le fichier.
3. Décochez ce dont vous n'avez pas besoin. Décochez les énormes tables de logs, de sessions ou d'analytics. DumpCleaner conserve les instructions entières intactes — pas d'INSERT coupés en deux.
4. Exportez. Écrivez un nouveau fichier .sql plus petit qui s'ouvre et s'importe enfin confortablement. Votre fichier d'origine n'est jamais modifié.

Comme il traite les dumps de 50 Go et plus à mémoire constante, vous n'avez plus à vous soucier de la RAM de votre Mac. Et puisqu'il lit la source et écrit une sortie séparée, le dump de départ reste exactement tel qu'il était.

Questions fréquentes