Mac で大きな SQL ダンプファイルを開く方法（クラッシュせずに）

本番データベースのダンプは簡単に数十ギガバイトに達します。それを通常のテキストエディタで開こうとした瞬間、Mac のファンが回り始め、ビーチボールが現れ、最終的にアプリが終了します。ときには他のウィンドウの未保存の作業まで道連れにします。

なぜエディタは大きなダンプで固まるのか

VS Code、テキストエディット、Sublime Text などは、瞬時にスクロール・検索・ハイライトできるよう、ファイル全体をメモリに読み込む設計になっています。2 MB のソースファイルなら問題ありません。しかし 40 GB のダンプでは、エディタは 40 GB（さらに内部データ構造のオーバーヘッド）を RAM に確保しようとします。

Mac の RAM は 16 GB か 32 GB です。ファイルが完全に読み込まれるずっと前に、システムは物理メモリを使い果たし、ディスクへのスワップを始め、動作が止まってしまいます。多くのエディタはそもそも拒否します。VS Code はフルエディタでファイルを約 50 MB に制限し、機能を削ったモードに切り替わります。テキストエディットは単に固まり、Sublime はクラッシュするまでメモリを確保し続けます。仮にファイルを開けたとしても、キー入力のたびに構文ハイライトと検索が数ギガバイトを再スキャンします。

核心の問題は、これらのツールがドキュメント全体へのランダムアクセスを前提にしていることです。ダンプにそれは不要です。ダンプは文の連続したリストであり、必要なのはストリーミングで通り抜けることだけです。

コマンドラインでのやり方

Mac の Unix ツールはもともとストリーミング処理するので、ファイル全体を読み込むことはありません。まず試す定番の手段です:

# ファイル全体を開かずに最初と最後の行だけ覗く
head -n 50 dump.sql
tail -n 50 dump.sql

# ダンプを part_aa, part_ab, ... という 100 MB のチャンクに分割
split -b 100m dump.sql part_

# 2つのマーカーの間にある1つのテーブルのブロックを抜き出す
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

これは機能しますが、脆く面倒です。split -b は生のバイト境界で切るので、INSERT 文の途中を真っ二つに切ってしまい、できたチャンクは単体では有効な SQL になりません。sed の範囲指定のトリックは、特定のダンプツールがたまたま出力する正確なマーカーに依存します。MySQL のバージョンを変えたり PostgreSQL に切り替えたりすると、パターンはもう一致しません。しかもどの方法も、ファイルの中身を実際に見せてはくれません。どのテーブルが 30 GB なのかを狙う前に、当て推量するしかないのです。

DumpCleaner で開いてフィルタリングする

DumpCleaner はまさにこのファイルサイズのために作られました。コマンドラインと同じようにダンプをストリーミングしますが、SQL の構造を理解するので、本物のテーブル一覧と、文単位で安全な出力が得られます:

1. ファイルをドラッグして入れます。DumpCleaner はダンプを約 1 MB のチャンクでストリーミングして開くので、50 GB のファイルでも約 50 MB の RAM で開き、何も固まりません。
2. すべてのテーブルを確認できます。ダンプをスキャンして各テーブルをサイズ付きで一覧表示するので、どれがファイルを肥大化させているのかがすぐ分かります。
3. 不要なものを選択解除します。巨大なログ・セッション・分析テーブルのチェックを外します。DumpCleaner は文全体をそのまま保つので、INSERT が途中で切れることはありません。
4. エクスポートします。ようやく快適に開いてインポートできる、より小さな新しい .sql ファイルを書き出します。元のファイルは一切変更されません。

50 GB 以上のダンプを一定のメモリで処理するので、Mac の RAM のことを一切気にする必要がありません。そしてソースを読み込んで別の出力を書き出すため、始めに手にしたダンプはそのままの状態で残ります。

よくある質問