Exportera endast schemat (strukturen) från en SQL-dump

Tre situationer dyker upp gång på gång:

• Sätt upp ett schema för staging eller CI — du vill ha den tomma tabellstrukturen så att tester kan köras mot verkliga kolumner, index och villkor, men du vill absolut inte skicka gigabyte av produktionsrader in i en slit-och-släng-miljö.
• Endast seed-data — schemat finns redan i måldatabasen, och du behöver bara INSERT-raderna för att fylla det, utan CREATE-satser som skulle krocka med det som redan finns där.
• Bli av med brus — dumpen är uppsvälld av logs-, sessions-, audit_trail- eller cache-tabeller med tiotals miljoner rader du aldrig vill importera.

Varför mysqldump --no-data inte räcker

Det klassiska rådet är mysqldump --no-data (endast struktur) eller mysqldump --no-create-info (endast data). Båda är exportflaggor: de ändrar vad en ny dump från en körande databas innehåller. De gör ingenting för en dump du redan har liggande på disk som en .sql-fil.

I praktiken kommer filen ofta från någon annan, eller från ett säkerhetskopieringsjobb, eller från en server du inte längre har live-åtkomst till. Du kan inte köra om mysqldump mot en databas som inte är nåbar — inloggningsuppgifterna är borta, servern är avvecklad, eller filen är helt enkelt allt du fick. Vid den punkten är flaggorna värdelösa, och du står med att redigera själva filen.

Det manuella sättet

Det uppenbara draget är att skala bort rader med grep eller sed. För att behålla strukturen och släppa datan:

# behåll allt utom INSERT-rader
grep -v '^INSERT INTO' dump.sql > schema.sql

# eller behåll bara INSERT-raderna för en fil med enbart data
grep '^INSERT INTO' dump.sql > data.sql

Detta ser bra ut på en liten, städad dump — och går sedan sönder på en riktig:

• Fleradiga INSERT-satser. En enda INSERT INTO … VALUES kan sträcka sig över tusentals rader. grep matchar den första raden och lämnar resten av värdena föräldralösa, vilket ger en trasig fil.
• Utökade inserts. mysqldump buntar många rader i en enda gigantisk sats. Radbaserade filter kan inte avgöra var en sådan sats slutar.
• Kommentarer och block. Villkorliga /*! … */-block, LOCK TABLES och -- -kommentarer varvas med datan, så ett naivt filter behåller antingen skräp eller klipper bort något som importen behöver.
• Endast data är värre. Ett rent grep '^INSERT' kastar bort de SET- och LOCK-satser som raderna är beroende av, och varje INSERT som inte börjar exakt i kolumn noll försvinner tyst.

Du slutar med att felsöka ditt eget filter i stället för att få ditt schema.

Endast struktur eller endast data med DumpCleaner

DumpCleaner förstår SQL-satser i stället för att matcha rader, så den skiljer struktur från data pålitligt — på filer av valfri storlek:

1. Dra in din .sql-dump i DumpCleaner (MySQL, MariaDB eller PostgreSQL). Den tolkar filen genom att strömma, så en flergigabytesdump läses in med konstant minne.
2. Växla de satstyper du vill ha: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Avmarkera INSERT INTO så får du endast struktur; avmarkera CREATE TABLE / CREATE INDEX så får du endast data.
3. Eller välj en förinställning — Endast struktur eller Endast data — för att ställa in varje växel i ett steg, och finjustera sedan per tabell om du vill.
4. Exportera. Du får en slimmad schemafil för staging eller CI, eller en ren dump med enbart data för seeding.

Eftersom filtret är satsmedvetet behålls eller släpps en fleradig utökad INSERT som en helhet — aldrig avklippt på mitten.

Den riktiga styrkan är att filtrering fungerar per satstyp och per tabell, och att de två kombineras. Du kan behålla strukturen på varje tabell men bara inkludera INSERT-data för de tre tabeller du faktiskt behöver — och lämna den 89 miljoner rader stora logs-tabellen som ett tomt skal. Det är något ingen --no-data-flagga kan uttrycka.

Vanliga frågor