一个生产数据库的转储轻轻松松就能达到几十 GB。你一旦尝试用普通文本编辑器打开它，Mac 的风扇就狂转、沙滩球出现，最后应用直接退出——有时还会连带丢掉其他窗口里未保存的工作。
编辑器为何卡死在大型转储上
VS Code、TextEdit、Sublime Text 之类的编辑器，设计上会把整个文件加载进内存，好让滚动、搜索和高亮都能即时响应。对一个 2 MB 的源文件来说这没问题。但对一个 40 GB 的转储，这意味着编辑器要在内存里分配 40 GB（还要加上它内部数据结构的额外开销）。
你的 Mac 只有 16 或 32 GB 内存。文件远没加载完，系统就已用尽物理内存，开始向磁盘交换，继而彻底卡死。大多数编辑器还会干脆拒绝：VS Code 对完整编辑器的文件大小上限约为 50 MB，超过就切进精简模式；TextEdit 直接挂起；Sublime 则一路分配内存直到崩溃。就算你真把文件打开了，每敲一个键，语法高亮和搜索都会重新扫描好几个 GB。
核心问题在于：这些工具都假定要对整个文档做随机访问。而转储并不需要这个——它就是一串按顺序排列的语句。你只需要流式地遍历它。
命令行的办法
你 Mac 上的 Unix 工具本身就是流式的，所以它们从不加载整个文件。它们是经典的第一选择：
# 不打开整个文件，先瞄一眼开头和结尾几行 head -n 50 dump.sql tail -n 50 dump.sql # 把转储切成 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 的区间技巧依赖某个特定转储工具恰好写出的确切标记；换一个 MySQL 版本，或改用 PostgreSQL，这个模式就再也匹配不上了。而且这些办法都没法让你看清文件里到底有什么——在能够下手之前，你还得靠猜哪张表才是那个 30 GB 的大家伙。
用 DumpCleaner 打开并筛选
DumpCleaner 正是为这种大小的文件而生。它像命令行那样流式处理转储，但它理解 SQL 结构，所以你能得到一份真实的表清单，以及安全的、语句感知的输出：
- 把文件拖进来。DumpCleaner 以约 1 MB 的分块流式打开转储——一个 50 GB 的文件大约只用 50 MB 内存就能打开，什么都不会卡。
- 看到每一张表。它扫描转储并列出每张表及其大小，让你一眼就看出是哪张表把文件撑大了。
- 取消你不需要的部分。去掉那些庞大的日志表、会话表或分析表的勾选。DumpCleaner 会保持整条语句完整——绝不会切出半截 INSERT。
- 导出。写出一个更小的、终于能顺畅打开和导入的新
.sql文件。你的原始文件绝不会被改动。
由于它以恒定内存处理 50 GB 乃至更大的转储，你完全不用再操心 Mac 的内存。而且因为它读取源文件、写出的是另一个独立的输出文件，你一开始拿到的转储会保持原封不动。
打开编辑器打不开的转储
DumpCleaner 以恒定内存流式处理任意大小的 SQL 转储——不崩溃、不交换、不苦等。拖入一个 50 GB 的文件，去掉你不需要的表，导出一个更小的。原生 macOS 与 iPadOS 应用，一次性买断。
在 App Store 下载常见问题
DumpCleaner 能处理多大的 SQL 转储？
没有固定上限。它把文件当作流、以小分块处理，所以 50 GB 乃至更大的转储和小文件一样能用——上限取决于你的磁盘，而不是内存。
DumpCleaner 会把整个文件加载进内存吗？
不会。与文本编辑器不同，它以小分块读取转储，内存大致恒定在 50 MB 左右，无论文件是 200 MB 还是 50 GB。
我能按表拆分转储吗？
可以。与 split 盲目地按字节边界切割不同，DumpCleaner 理解表结构。取消你不想要的表的勾选，导出一个只包含你保留的表的干净文件。
DumpCleaner 会修改我的原始文件吗？
不会。源转储只会被读取——DumpCleaner 始终写出一个新文件，所以你的原始文件保持不动。