Как открыть большой SQL-дамп на Mac (без вылета)

Дамп производственной базы данных легко достигает десятков гигабайт. Как только вы пытаетесь открыть его в обычном текстовом редакторе, вентилятор Mac раскручивается, появляется «радужный кружок», и в итоге приложение завершается — иногда унося с собой несохранённую работу в других окнах.

Почему редакторы захлёбываются на больших дампах

VS Code, TextEdit, Sublime Text и им подобные спроектированы так, чтобы загружать весь файл в память и мгновенно прокручивать, искать и подсвечивать синтаксис. Это нормально для исходника на 2 МБ. Но для дампа на 40 ГБ это значит, что редактор пытается выделить 40 ГБ (плюс накладные расходы на внутренние структуры данных) в ОЗУ.

У вашего Mac 16 или 32 ГБ. Задолго до полной загрузки файла системе не хватает физической памяти, она начинает выгружать данные на диск и практически замирает. Большинство редакторов к тому же прямо отказываются: VS Code ограничивает полноценный редактор примерно 50 МБ и переходит в урезанный режим, TextEdit просто зависает, а Sublime выделяет память до тех пор, пока не падает. Даже если файл удалось открыть, подсветка синтаксиса и поиск будут заново сканировать гигабайты при каждом нажатии клавиши.

Ключевая проблема: эти инструменты предполагают произвольный доступ ко всему документу. Дампу это не нужно — он представляет собой последовательный список инструкций. Через него нужно лишь проходить потоком.

Способ через командную строку

Утилиты Unix на вашем Mac уже работают потоково, поэтому никогда не загружают файл целиком. Это классический первый вариант:

# Заглянуть в первые и последние строки, не открывая весь файл
head -n 50 dump.sql
tail -n 50 dump.sql

# Разбить дамп на куски по 100 МБ с именами part_aa, part_ab, ...
split -b 100m dump.sql part_

# Вытащить блок одной таблицы между двумя маркерами
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

Это работает, но хрупко и утомительно. split -b режет по границам сырых байтов, поэтому легко разрубит INSERT-инструкцию прямо посередине — получившиеся куски сами по себе не являются валидным SQL. Трюк с диапазоном sed зависит от точных маркеров, которые генерирует конкретный инструмент дампа; смените версию MySQL или перейдите на PostgreSQL — и шаблон перестанет совпадать. И ничто из этого не даёт вам представления о том, что на самом деле внутри файла — вы гадаете, какая таблица весит 30 ГБ, ещё до того, как сможете её нацелить.

Открыть и отфильтровать с DumpCleaner

DumpCleaner создан именно для файлов такого размера. Он проходит дамп потоком, как командная строка, но понимает структуру SQL, поэтому вы получаете настоящий список таблиц и безопасный вывод с учётом границ инструкций:

1. Перетащите файл. DumpCleaner открывает дамп, читая его потоком кусками по ~1 МБ — файл на 50 ГБ открывается примерно с 50 МБ ОЗУ, так что ничто не зависает.
2. Увидьте каждую таблицу. Программа сканирует дамп и перечисляет каждую таблицу с её размером, так что вы сразу видите, какая раздувает файл.
3. Снимите отметку с ненужного. Снимите отметки с гигантских таблиц логов, сессий или аналитики. DumpCleaner сохраняет инструкции целиком — никаких обрезанных INSERT-ов.
4. Экспортируйте. Запишите новый файл .sql поменьше, который наконец нормально открывается и импортируется. Ваш исходный файл никогда не изменяется.

Поскольку программа обрабатывает дампы от 50 ГБ и больше с постоянным расходом памяти, вам вообще не нужно думать об ОЗУ вашего Mac. А так как она читает исходник и пишет отдельный вывод, дамп, с которого вы начали, остаётся ровно таким, каким был.

Часто задаваемые вопросы