Exporter uniquement le schéma (structure) d'un dump SQL

Trois situations reviennent sans cesse :

• Monter un schéma pour un environnement de préproduction ou de CI — vous voulez la structure de tables vide pour que les tests s'exécutent contre de vraies colonnes, index et contraintes, mais vous ne voulez absolument pas déverser des gigaoctets de lignes de production dans un environnement jetable.
• Uniquement les données de départ — le schéma existe déjà dans la base cible, et vous n'avez besoin que des lignes INSERT pour le peupler, sans les instructions CREATE qui entreraient en collision avec l'existant.
• Se débarrasser du bruit — le dump est gonflé par des tables logs, sessions, audit_trail ou cache comptant des dizaines de millions de lignes que vous ne voulez jamais importer.

Pourquoi mysqldump --no-data ne suffit pas

Le conseil classique est mysqldump --no-data (structure uniquement) ou mysqldump --no-create-info (données uniquement). Ce sont tous deux des options d'export : elles changent ce que contient un dump neuf issu d'une base en fonctionnement. Elles ne font rien pour un dump que vous avez déjà sur disque sous forme de fichier .sql.

En pratique, le fichier arrive souvent de quelqu'un d'autre, d'une tâche de sauvegarde, ou d'un serveur auquel vous n'avez plus d'accès en direct. Vous ne pouvez pas relancer mysqldump contre une base qui n'est pas joignable — les identifiants ont disparu, le serveur est décommissionné, ou le fichier est simplement tout ce qu'on vous a remis. À ce stade, les options sont inutiles, et il ne vous reste qu'à modifier le fichier lui-même.

La méthode manuelle

Le réflexe évident est de retirer des lignes avec grep ou sed. Pour garder la structure et supprimer les données :

# garder tout sauf les lignes INSERT
grep -v '^INSERT INTO' dump.sql > schema.sql

# ou ne garder que les lignes INSERT pour un fichier de données seul
grep '^INSERT INTO' dump.sql > data.sql

Cela paraît correct sur un petit dump bien rangé — puis se casse sur un vrai :

• INSERT multilignes. Un seul INSERT INTO … VALUES peut s'étendre sur des milliers de lignes. grep correspond à la première ligne et laisse le reste des valeurs orphelin, produisant un fichier cassé.
• Inserts étendus. mysqldump regroupe de nombreuses lignes dans une seule instruction géante. Les filtres basés sur les lignes ne peuvent pas dire où une telle instruction se termine.
• Commentaires et blocs. Les blocs conditionnels /*! … */, les LOCK TABLES et les commentaires -- s'entremêlent avec les données, si bien qu'un filtre naïf garde du superflu ou coupe quelque chose dont l'import a besoin.
• Les données seules, c'est pire. Un pur grep '^INSERT' jette les instructions SET et LOCK dont dépendent les lignes, et tout INSERT qui ne commence pas exactement à la colonne zéro disparaît silencieusement.

Vous finissez par déboguer votre propre filtre au lieu d'obtenir votre schéma.

Structure seule ou données seules avec DumpCleaner

DumpCleaner comprend les instructions SQL au lieu de faire correspondre des lignes, si bien qu'il sépare structure et données de façon fiable — sur des fichiers de toute taille :

1. Glissez votre dump .sql dans DumpCleaner (MySQL, MariaDB ou PostgreSQL). Il analyse le fichier en flux, un dump de plusieurs gigaoctets se charge donc à mémoire constante.
2. Activez les types d'instructions que vous voulez : CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Décochez INSERT INTO et vous obtenez la structure seule ; décochez CREATE TABLE / CREATE INDEX et vous obtenez les données seules.
3. Ou choisissez un préréglage — Structure seule ou Données seules — pour régler tous les interrupteurs d'un coup, puis affinez par table si vous le souhaitez.
4. Exportez. Vous obtenez un fichier de schéma léger pour la préproduction ou la CI, ou un dump de données propre pour l'initialisation.

Comme le filtre est conscient des instructions, un INSERT étendu multiligne est gardé ou supprimé en entier — jamais coupé au milieu.

La vraie puissance réside dans le fait que le filtrage fonctionne par type d'instruction et par table, et que les deux se combinent. Vous pouvez garder la structure de chaque table mais n'inclure les données INSERT que pour les trois tables dont vous avez réellement besoin — laissant la table logs de 89 millions de lignes comme une coquille vide. C'est quelque chose qu'aucune option --no-data ne peut exprimer.

Questions fréquentes