Eksporter kun skjemaet (strukturen) fra en SQL-dump

Tre situasjoner dukker stadig opp:

• Sette opp et skjema for staging eller CI — du vil ha den tomme tabellstrukturen slik at tester kan kjøre mot ekte kolonner, indekser og begrensninger, men du vil absolutt ikke sende gigabyte med produksjonsrader inn i et bruk-og-kast-miljø.
• Kun seed-data — skjemaet finnes allerede i måldatabasen, og du trenger bare INSERT-radene for å fylle det, uten CREATE-setninger som ville kollidert med det som er der.
• Bli kvitt støy — dumpen er oppsvulmet av logs-, sessions-, audit_trail- eller cache-tabeller med titalls millioner rader du aldri vil importere.

Hvorfor mysqldump --no-data ikke er nok

Det klassiske rådet er mysqldump --no-data (kun struktur) eller mysqldump --no-create-info (kun data). Begge er eksportflagg: de endrer hva en fersk dump fra en kjørende database inneholder. De gjør ingenting for en dump du allerede har liggende på disk som en .sql-fil.

I praksis kommer filen ofte fra noen andre, eller fra en sikkerhetskopieringsjobb, eller fra en server du ikke lenger har direkte tilgang til. Du kan ikke kjøre mysqldump på nytt mot en database som ikke er tilgjengelig — legitimasjonen er borte, serveren er avviklet, eller filen er rett og slett alt du fikk overlevert. På det punktet er flaggene ubrukelige, og du sitter igjen med å redigere selve filen.

Den manuelle måten

Det opplagte grepet er å fjerne linjer med grep eller sed. For å beholde strukturen og droppe dataene:

# behold alt unntatt INSERT-rader
grep -v '^INSERT INTO' dump.sql > schema.sql

# eller behold bare INSERT-radene for en fil med kun data
grep '^INSERT INTO' dump.sql > data.sql

Dette ser greit ut på en liten, ryddig dump — og bryter så sammen på en ekte:

• Flerlinjers INSERT-er. En enkelt INSERT INTO … VALUES kan strekke seg over tusenvis av linjer. grep matcher den første linjen og lar resten av verdiene bli foreldreløse, noe som gir en ødelagt fil.
• Utvidede inserts. mysqldump samler mange rader i én gigantisk setning. Linjebaserte filtre kan ikke se hvor en slik setning slutter.
• Kommentarer og blokker. Betingede /*! … */-blokker, LOCK TABLES og -- -kommentarer flettes inn med dataene, så et naivt filter enten beholder søppel eller kutter bort noe importen trenger.
• Kun data er verre. En ren grep '^INSERT' kaster bort SET- og LOCK-setningene radene avhenger av, og enhver INSERT som ikke starter nøyaktig på kolonne null forsvinner stille.

Du ender opp med å feilsøke ditt eget filter i stedet for å få skjemaet ditt.

Kun struktur eller kun data med DumpCleaner

DumpCleaner forstår SQL-setninger i stedet for å matche linjer, så den skiller struktur fra data pålitelig — på filer av enhver størrelse:

1. Dra .sql-dumpen din inn i DumpCleaner (MySQL, MariaDB eller PostgreSQL). Den parser filen ved å strømme, så en dump på flere gigabyte lastes med konstant minnebruk.
2. Slå av og på setningstypene du vil ha: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Fjern haken på INSERT INTO, så får du kun struktur; fjern haken på CREATE TABLE / CREATE INDEX, så får du kun data.
3. Eller velg en forhåndsinnstilling — Kun struktur eller Kun data — for å sette hver bryter i ett steg, og finjuster så per tabell om du vil.
4. Eksporter. Du får en slank skjemafil for staging eller CI, eller en ren dump med kun data for seeding.

Fordi filteret er setningsbevisst, beholdes eller droppes en flerlinjers utvidet INSERT som en helhet — aldri kuttet på midten.

Den virkelige styrken er at filtreringen fungerer per setningstype og per tabell, og de to kombineres. Du kan beholde strukturen til hver tabell, men inkludere INSERT-data bare for de tre tabellene du faktisk trenger — og la logs-tabellen på 89 millioner rader stå som et tomt skall. Det er noe intet --no-data-flagg kan uttrykke.

Ofte stilte spørsmål