Alleen het schema (structuur) exporteren uit een SQL-dump

Drie situaties komen steeds terug:

• Een schema opzetten voor staging of CI — je wilt de lege tabelstructuur zodat tests kunnen draaien tegen echte kolommen, indexen en constraints, maar je wilt absoluut geen gigabytes productie-rijen naar een wegwerpomgeving sturen.
• Alleen seed-data — het schema bestaat al in de doeldatabase, en je hebt alleen de INSERT-rijen nodig om die te vullen, zonder CREATE-statements die zouden botsen met wat er al is.
• Ruis kwijtraken — de dump is opgeblazen door logs-, sessions-, audit_trail- of cache-tabellen met tientallen miljoenen rijen die je nooit wilt importeren.

Waarom mysqldump --no-data niet genoeg is

Het klassieke advies is mysqldump --no-data (alleen structuur) of mysqldump --no-create-info (alleen data). Beide zijn export-flags: ze veranderen wat een verse dump van een draaiende database bevat. Ze doen niets voor een dump die je al als .sql-bestand op schijf hebt staan.

In de praktijk komt het bestand vaak van iemand anders, of van een backup-taak, of van een server waar je geen live toegang meer toe hebt. Je kunt mysqldump niet opnieuw uitvoeren tegen een database die onbereikbaar is — de inloggegevens zijn weg, de server is buiten gebruik gesteld, of het bestand is simpelweg alles wat je in handen kreeg. Op dat punt zijn de flags nutteloos, en zit je met het bewerken van het bestand zelf.

De handmatige manier

De voor de hand liggende zet is regels strippen met grep of sed. Om de structuur te houden en de data weg te laten:

# houd alles behalve INSERT-rijen
grep -v '^INSERT INTO' dump.sql > schema.sql

# of houd alleen de INSERT-rijen voor een bestand met alleen data
grep '^INSERT INTO' dump.sql > data.sql

Dit ziet er prima uit op een kleine, nette dump — en breekt dan op een echte:

• Meerregelige INSERTs. Eén enkele INSERT INTO … VALUES kan duizenden regels beslaan. grep matcht de eerste regel en laat de rest van de waarden verweesd achter, wat een kapot bestand oplevert.
• Extended inserts. mysqldump bundelt veel rijen in één gigantisch statement. Regelgebaseerde filters kunnen niet zien waar zo'n statement eindigt.
• Commentaar en blokken. Voorwaardelijke /*! … */-blokken, LOCK TABLES en -- -commentaar staan tussen de data door, dus een naïef filter houdt óf rommel over óf snijdt iets weg dat de import nodig heeft.
• Alleen-data is erger. Een pure grep '^INSERT' gooit de SET- en LOCK-statements weg waar de rijen van afhankelijk zijn, en elke INSERT die niet precies op kolom nul begint verdwijnt stilzwijgend.

Je eindigt met het debuggen van je eigen filter in plaats van dat je je schema krijgt.

Alleen structuur of alleen data met DumpCleaner

DumpCleaner begrijpt SQL-statements in plaats van regels te matchen, dus het splitst structuur van data betrouwbaar — bij bestanden van elke grootte:

1. Sleep je .sql-dump in DumpCleaner (MySQL, MariaDB of PostgreSQL). Het parseert het bestand door te streamen, dus een dump van meerdere gigabytes laadt met constant geheugengebruik.
2. Schakel de statement-types in die je wilt: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Vink INSERT INTO uit en je krijgt alleen structuur; vink CREATE TABLE / CREATE INDEX uit en je krijgt alleen data.
3. Of kies een preset — Alleen structuur of Alleen data — om elke schakelaar in één stap in te stellen, en verfijn daarna per tabel als je wilt.
4. Exporteer. Je krijgt een compact schema-bestand voor staging of CI, of een schone dump met alleen data om te seeden.

Omdat het filter statement-bewust is, wordt een meerregelige extended INSERT als geheel behouden of weggelaten — nooit in het midden doorgesneden.

De echte kracht is dat het filteren per statement-type en per tabel werkt, en dat de twee combineren. Je kunt de structuur van elke tabel houden maar INSERT-data alleen voor de drie tabellen die je echt nodig hebt meenemen — waardoor de logs-tabel met 89 miljoen rijen een lege huls blijft. Dat is iets wat geen enkele --no-data-flag kan uitdrukken.

Veelgestelde vragen