Hogyan nyiss meg egy nagy SQL dump fájlt Macen (összeomlás nélkül)

Egy éles adatbázis dumpja könnyen elérheti a több tíz gigabájtot. Abban a pillanatban, ahogy megpróbálod megnyitni egy szokványos szövegszerkesztőben, felpörög a Mac ventilátora, megjelenik a pörgő kerék, és végül az alkalmazás kilép – néha magával rántva a többi ablakban lévő mentetlen munkádat is.

Miért akadnak be a szerkesztők a nagy dumpokon

A VS Code, a TextEdit, a Sublime Text és társaik úgy vannak megtervezve, hogy a teljes fájlt a memóriába töltsék, így azonnal tudnak görgetni, keresni és kiemelni. Egy 2 MB-os forrásfájlnál ez rendben is van. Egy 40 GB-os dumpnál viszont azt jelenti, hogy a szerkesztő megpróbál 40 GB-ot (plusz a belső adatszerkezetei többletét) lefoglalni a RAM-ban.

A Macedben 16 vagy 32 GB van. Jóval azelőtt, hogy a fájl teljesen betöltődne, a rendszerből elfogy a fizikai memória, elkezd lemezre lapozni, és leáll. A legtöbb szerkesztő egyenesen meg is tagadja: a VS Code a teljes szerkesztő esetén körülbelül 50 MB-nál korlátozza a fájlokat, és lecsupaszított módba vált, a TextEdit egyszerűen lefagy, a Sublime pedig addig foglal memóriát, amíg össze nem omlik. Még ha meg is nyitod a fájlt, a szintaxiskiemelés és a keresés minden billentyűleütésnél újraolvas gigabájtokat.

Az alapprobléma: ezek az eszközök véletlen hozzáférést feltételeznek a teljes dokumentumhoz. Egy dumpnak erre nincs szüksége – ez utasítások szekvenciális listája. Csak végig kell streamelned rajta.

A parancssoros út

A Macen lévő Unix-eszközök már eleve streamelnek, így soha nem töltik be a teljes fájlt. Ezek a klasszikus első megoldások:

# Kukkants be az első és utolsó sorokba a teljes fájl megnyitása nélkül
head -n 50 dump.sql
tail -n 50 dump.sql

# Oszd fel a dumpot 100 MB-os darabokra part_aa, part_ab, ... néven
split -b 100m dump.sql part_

# Húzd ki egy tábla blokkját két jelölő között
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

Ez működik, de törékeny és fárasztó. A split -b nyers bájthatárokon vág, így simán belevág egy INSERT utasítás közepébe – a keletkező darabok önmagukban nem érvényes SQL-ek. A sed tartományos trükk azon a pontos jelölőn múlik, amit egy adott dump-eszköz éppen kiír; változtass MySQL-verziót vagy válts PostgreSQL-re, és a minta már nem illeszkedik. És egyik sem ad rálátást arra, hogy mi van valójában a fájlban – találgatsz, melyik a 30 GB-os tábla, mielőtt egyáltalán meg tudnád célozni.

Nyisd meg és szűrd a DumpCleanerrel

A DumpCleaner pontosan erre a fájlméretre készült. Úgy streameli a dumpot, ahogy a parancssor, de érti az SQL szerkezetét, így valódi táblalistát és biztonságos, utasítás-tudatos kimenetet kapsz:

1. Húzd be a fájlt. A DumpCleaner ~1 MB-os darabokban streamelve nyitja meg a dumpot – egy 50 GB-os fájl körülbelül 50 MB RAM mellett nyílik meg, így semmi nem fagy le.
2. Lásd az összes táblát. Beolvassa a dumpot, és felsorolja az egyes táblákat a méretükkel együtt, így azonnal kiszúrod, melyik duzzasztja fel a fájlt.
3. Vedd ki a jelölést arról, amire nincs szükséged. Vedd ki a pipát a hatalmas log-, session- vagy analitikai tábláknál. A DumpCleaner egészben tartja az utasításokat – nincsenek félbevágott INSERT-ek.
4. Exportálj. Írj ki egy új, kisebb .sql fájlt, ami végre kényelmesen megnyílik és importálódik. Az eredeti fájlod soha nem módosul.

Mivel az 50 GB-os és nagyobb dumpokat is állandó memóriával dolgozza fel, egyáltalán nem kell a Maced RAM-jával foglalkoznod. És mivel a forrást olvassa, és külön kimenetet ír, a dump, amellyel kezdted, pontosan olyan marad, amilyen volt.

Gyakran ismételt kérdések