Exportă doar schema (structura) dintr-un dump SQL

Trei situații apar mereu:

• Ridici o schemă pentru staging sau CI — vrei structura de tabele goală, ca testele să ruleze pe coloane, indexuri și constrângeri reale, dar nu vrei nicidecum să trimiți gigaocteți de rânduri de producție într-un mediu de unică folosință.
• Doar date de inițializare — schema există deja în baza de date țintă și ai nevoie doar de rândurile INSERT ca s-o populezi, fără instrucțiuni CREATE care ar intra în conflict cu ce e acolo.
• Scapi de zgomot — dump-ul este umflat de tabelele logs, sessions, audit_trail sau cache, cu zeci de milioane de rânduri pe care nu vrei să le imporți niciodată.

De ce mysqldump --no-data nu este suficient

Sfatul clasic este mysqldump --no-data (doar structura) sau mysqldump --no-create-info (doar datele). Ambele sunt flag-uri de export: schimbă ce conține un dump proaspăt dintr-o bază de date în funcțiune. Nu fac nimic pentru un dump pe care îl ai deja pe disc ca fișier .sql.

În practică, fișierul ajunge adesea de la altcineva, dintr-o sarcină de backup, sau de la un server la care nu mai ai acces live. Nu poți rula din nou mysqldump pe o bază de date care nu e accesibilă — credențialele sunt pierdute, serverul este scos din uz, sau fișierul este pur și simplu tot ce ți s-a dat. În acel moment flag-urile sunt inutile și rămâi să editezi fișierul însuși.

Calea manuală

Mișcarea evidentă este să elimini linii cu grep sau sed. Ca să păstrezi structura și să elimini datele:

# păstrează totul în afară de rândurile INSERT
grep -v '^INSERT INTO' dump.sql > schema.sql

# sau păstrează doar rândurile INSERT pentru un fișier doar cu date
grep '^INSERT INTO' dump.sql > data.sql

Asta pare în regulă pe un dump mic și ordonat — și apoi se strică pe unul real:

• INSERT-uri pe mai multe linii. Un singur INSERT INTO … VALUES poate întinde pe mii de linii. grep potrivește prima linie și lasă restul valorilor orfane, producând un fișier stricat.
• Inserări extinse. mysqldump grupează multe rânduri într-o singură instrucțiune uriașă. Filtrele bazate pe linii nu pot spune unde se termină o astfel de instrucțiune.
• Comentarii și blocuri. Blocurile condiționale /*! … */, LOCK TABLES și comentariile -- se întrepătrund cu datele, așa că un filtru naiv fie păstrează gunoi, fie taie ceva de care importul are nevoie.
• Doar cu date e și mai rău. Un simplu grep '^INSERT' aruncă instrucțiunile SET și LOCK de care depind rândurile, iar orice INSERT care nu începe exact la coloana zero dispare în tăcere.

Ajungi să-ți depanezi propriul filtru în loc să-ți obții schema.

Doar structura sau doar datele cu DumpCleaner

DumpCleaner înțelege instrucțiunile SQL în loc să potrivească linii, așa că separă structura de date în mod fiabil — pe fișiere de orice dimensiune:

1. Trage dump-ul tău .sql în DumpCleaner (MySQL, MariaDB sau PostgreSQL). Parsează fișierul prin streaming, așa că un dump de mai mulți gigaocteți se încarcă cu memorie constantă.
2. Comută tipurile de instrucțiuni pe care le vrei: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. Debifează INSERT INTO și obții doar structura; debifează CREATE TABLE / CREATE INDEX și obții doar datele.
3. Sau alege o presetare — Doar structura sau Doar datele — pentru a seta fiecare comutator dintr-un pas, apoi ajustează pe fiecare tabel dacă vrei.
4. Exportă. Obții un fișier de schemă suplu pentru staging sau CI, sau un dump curat doar cu date pentru inițializare.

Pentru că filtrul este conștient de instrucțiuni, un INSERT extins pe mai multe linii este păstrat sau eliminat în întregime — niciodată tăiat la mijloc.

Adevărata putere este că filtrarea funcționează pe fiecare tip de instrucțiune și pe fiecare tabel, iar cele două se combină. Poți păstra structura fiecărui tabel, dar să incluzi datele INSERT doar pentru cele trei tabele de care ai nevoie cu adevărat — lăsând tabelul logs cu 89 de milioane de rânduri ca o carcasă goală. Asta e ceva ce niciun flag --no-data nu poate exprima.

Întrebări frecvente