Eksportér kun skemaet (strukturen) fra en SQL-dump

Tre situationer dukker op igen og igen:

• Stil et skema op til staging eller CI — du vil have den tomme tabelstruktur, så tests kan køre mod rigtige kolonner, indekser og constraints, men du vil absolut ikke sende gigabyte af produktionsrækker ind i et engangsmiljø.
• Kun seed-data — skemaet findes allerede i måldatabasen, og du har bare brug for INSERT-rækkerne til at fylde det, uden CREATE-sætninger, der ville kollidere med det, der er der.
• Slip af med støj — dumpen er pustet op af logs-, sessions-, audit_trail- eller cache-tabeller med titusinder af rækker, du aldrig vil importere.

Hvorfor mysqldump --no-data ikke er nok

Det klassiske råd er mysqldump --no-data (kun struktur) eller mysqldump --no-create-info (kun data). Begge er eksport-flag: de ændrer, hvad en frisk dump fra en kørende database indeholder. De gør intet for en dump, du allerede har liggende på disken som en .sql-fil.

I praksis ankommer filen ofte fra en anden, eller fra et backup-job, eller fra en server, du ikke længere har live-adgang til. Du kan ikke køre mysqldump igen mod en database, der ikke er tilgængelig — legitimationsoplysningerne er væk, serveren er nedlagt, eller filen er simpelthen alt, du fik udleveret. På det tidspunkt er flagene ubrugelige, og du er tvunget til at redigere selve filen.

Den manuelle måde

Det oplagte træk er at fjerne linjer med grep eller sed. For at beholde strukturen og droppe dataene:

# behold alt undtagen INSERT-rækker
grep -v '^INSERT INTO' dump.sql > schema.sql

# eller behold kun INSERT-rækkerne til en fil med kun data
grep '^INSERT INTO' dump.sql > data.sql

Det ser fint ud på en lille, ryddelig dump — og går så i stykker på en rigtig:

• Flerlinjede INSERTs. En enkelt INSERT INTO … VALUES kan spænde over tusinder af linjer. grep matcher den første linje og efterlader resten af værdierne forældreløse, hvilket producerer en ødelagt fil.
• Udvidede inserts. mysqldump samler mange rækker i én kæmpe sætning. Linjebaserede filtre kan ikke se, hvor en sådan sætning slutter.
• Kommentarer og blokke. Betingede /*! … */-blokke, LOCK TABLES og -- -kommentarer flettes sammen med dataene, så et naivt filter enten beholder skrald eller skærer noget væk, som importen har brug for.
• Kun data er værre. Et rent grep '^INSERT' smider de SET- og LOCK-sætninger væk, som rækkerne afhænger af, og enhver INSERT, der ikke starter præcis ved kolonne nul, forsvinder stille.

Du ender med at fejlfinde dit eget filter i stedet for at få dit skema.

Kun struktur eller kun data med DumpCleaner

DumpCleaner forstår SQL-sætninger i stedet for at matche linjer, så den adskiller struktur fra data pålideligt — på filer af enhver størrelse:

1. Træk din .sql-dump ind i DumpCleaner (MySQL, MariaDB eller PostgreSQL). Den parser filen ved at streame, så en dump på flere gigabyte indlæses med konstant hukommelse.
2. Slå de sætningstyper til/fra, du vil have: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Fjern fluebenet ved INSERT INTO, og du får kun struktur; fjern fluebenet ved CREATE TABLE / CREATE INDEX, og du får kun data.
3. Eller vælg en forudindstilling — Kun struktur eller Kun data — for at sætte alle knapper i ét trin, og forfin så pr. tabel, hvis du vil.
4. Eksportér. Du får en slank skemafil til staging eller CI, eller en ren dump med kun data til seeding.

Fordi filteret er sætningsbevidst, beholdes eller droppes en flerlinjet udvidet INSERT som en helhed — aldrig skåret over på midten.

Den virkelige styrke er, at filtrering virker pr. sætningstype og pr. tabel, og de to kombineres. Du kan beholde strukturen af hver tabel, men kun inkludere INSERT-data for de tre tabeller, du faktisk har brug for — så logtabellen med 89 millioner rækker bliver en tom skal. Det er noget, intet --no-data-flag kan udtrykke.

Ofte stillede spørgsmål