如何在 Mac 上開啟大型 SQL dump 檔案（不會當機）

正式環境的資料庫 dump 動輒可達數十 GB。當你試著用一般文字編輯器開啟它的那一刻，Mac 的風扇開始狂轉、彩球出現，最後應用程式直接結束——有時還會連帶把其他視窗裡未儲存的工作一起帶走。

為什麼編輯器撐不住大型 dump

VS Code、TextEdit、Sublime Text 這類工具的設計，是把整個檔案載入記憶體，才能即時捲動、搜尋與高亮。對 2 MB 的原始碼檔案來說沒問題。但對 40 GB 的 dump 而言，這代表編輯器試圖在 RAM 中配置 40 GB（外加其內部資料結構的額外開銷）。

你的 Mac 只有 16 或 32 GB。早在檔案完全載入之前，系統就用光了實體記憶體，開始把資料交換到磁碟，接著整台機器慢到停擺。多數編輯器乾脆直接拒絕：VS Code 對完整編輯模式設有約 50 MB 的檔案上限，超過就切換到精簡模式；TextEdit 只會一直卡住；Sublime 則會不斷配置記憶體直到當機。就算你成功開啟檔案，語法高亮與搜尋也會在每次按鍵時重新掃描數 GB 的內容。

核心問題在於：這些工具都假設你要對整份文件隨機存取。但 dump 並不需要如此——它只是一串依序排列的陳述式。你只需要串流掃過它即可。

命令列的做法

Mac 上的 Unix 工具本來就是串流處理，因此它們永遠不會載入整個檔案。它們是最經典的第一選擇：

# 不用開整個檔案，先看最前面和最後面幾行
head -n 50 dump.sql
tail -n 50 dump.sql

# 把 dump 切成 100 MB 的區塊，命名為 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 的範圍技巧則仰賴某個特定 dump 工具剛好輸出的精確標記；只要換個 MySQL 版本或改用 PostgreSQL，這個樣式就對不上了。而且這些做法都沒辦法讓你看清楚檔案裡到底有什麼——你連要鎖定哪個資料表之前，都得先猜哪一個才是那個 30 GB 的大表。

用 DumpCleaner 開啟並過濾

DumpCleaner 正是為這種檔案大小而生。它像命令列一樣串流處理 dump，但它理解 SQL 結構，因此你會得到一份真正的資料表清單，以及安全、以陳述式為單位的輸出：

1. 把檔案拖進來。DumpCleaner 以約 1 MB 為單位串流開啟 dump——一個 50 GB 的檔案大約只用 50 MB 記憶體就能開啟，什麼都不會卡住。
2. 看見每一個資料表。它掃描 dump 並列出每個資料表及其大小，讓你立刻看出是哪一個把檔案撐大了。
3. 取消勾選你不需要的。取消勾選那些龐大的 log、session 或分析類資料表。DumpCleaner 會保持每個陳述式完整——不會有被切一半的 INSERT。
4. 匯出。寫出一個更小、終於能順利開啟並匯入的新 .sql 檔案。你的原始檔案完全不會被修改。

因為它以恆定記憶體處理 50 GB 甚至更大的 dump，你完全不必去操心 Mac 的 RAM。而且由於它讀取來源、另寫一份輸出，你一開始的那份 dump 會保持原封不動。

常見問題