Cum deschizi un fișier dump SQL mare pe Mac (fără să se blocheze)

Un dump al unei baze de date de producție poate ajunge cu ușurință la zeci de gigaocteți. În momentul în care încerci să-l deschizi într-un editor de text obișnuit, ventilatorul Mac-ului tău pornește, apare rotița de așteptare și în cele din urmă aplicația se închide — uneori luând cu ea și munca nesalvată din alte ferestre.

De ce editoarele se împotmolesc la dump-urile mari

VS Code, TextEdit, Sublime Text și celelalte sunt concepute să încarce întregul fișier în memorie, ca să poată derula, căuta și evidenția instant. Asta e în regulă pentru un fișier sursă de 2 MB. Pentru un dump de 40 GB înseamnă că editorul încearcă să aloce 40 GB (plus supraîncărcarea pentru structurile sale interne de date) în RAM.

Mac-ul tău are 16 sau 32 GB. Cu mult înainte ca fișierul să fie complet încărcat, sistemul rămâne fără memorie fizică, începe să facă swap pe disc și se blochează. Majoritatea editoarelor refuză de-a dreptul: VS Code limitează fișierele la aproximativ 50 MB pentru editorul complet și trece într-un mod redus, TextEdit pur și simplu îngheață, iar Sublime alocă până se blochează. Chiar dacă reușești să deschizi fișierul, evidențierea sintaxei și căutarea vor re-scana gigaocteți la fiecare apăsare de tastă.

Problema de bază: aceste instrumente presupun acces aleatoriu la întregul document. Un dump nu are nevoie de asta — este o listă secvențială de instrucțiuni. Trebuie doar să faci streaming prin el.

Calea din linia de comandă

Instrumentele Unix de pe Mac-ul tău fac deja streaming, așa că nu încarcă niciodată întregul fișier. Sunt prima soluție clasică la care apelezi:

# Aruncă o privire la primele și ultimele linii fără a deschide întregul fișier
head -n 50 dump.sql
tail -n 50 dump.sql

# Împarte dump-ul în bucăți de 100 MB denumite part_aa, part_ab, ...
split -b 100m dump.sql part_

# Extrage blocul unui singur tabel între două marcaje
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

Funcționează, dar este fragil și obositor. split -b taie pe granițe de octeți brute, așa că va tăia direct prin mijlocul unei instrucțiuni INSERT — bucățile rezultate nu sunt SQL valid pe cont propriu. Trucul cu intervalul sed depinde de marcajele exacte pe care se întâmplă să le emită un anumit instrument de dump; schimbă versiunea MySQL sau treci la PostgreSQL, iar tiparul nu se mai potrivește. Și niciunul dintre acestea nu-ți oferă o imagine a ceea ce se află de fapt în fișier — ghicești care tabel este cel de 30 GB înainte de a-l putea măcar viza.

Deschide-l și filtrează-l cu DumpCleaner

DumpCleaner a fost creat exact pentru această dimensiune de fișier. Face streaming prin dump la fel ca linia de comandă, dar înțelege structura SQL, astfel încât obții o listă reală de tabele și un rezultat sigur, conștient de instrucțiuni:

1. Trage fișierul înăuntru. DumpCleaner deschide dump-ul făcând streaming în bucăți de ~1 MB — un fișier de 50 GB se deschide cu aproximativ 50 MB de RAM, așa că nimic nu îngheață.
2. Vezi fiecare tabel. Scanează dump-ul și listează fiecare tabel cu dimensiunea sa, astfel încât identifici imediat care umflă fișierul.
3. Deselectează ce nu-ți trebuie. Debifează tabelele gigantice de jurnale, sesiuni sau analitice. DumpCleaner păstrează instrucțiunile întregi intacte — fără INSERT-uri tăiate pe jumătate.
4. Exportă. Scrie un fișier .sql nou, mai mic, care în sfârșit se deschide și se importă comod. Fișierul original nu este niciodată modificat.

Pentru că procesează dump-uri de 50 GB și mai mari cu memorie constantă, nu trebuie să te gândești deloc la RAM-ul Mac-ului tău. Și, întrucât citește sursa și scrie un rezultat separat, dump-ul cu care ai pornit rămâne exact cum a fost.

Întrebări frecvente