从 SQL 转储中只导出表结构（Schema）

有三种情形反复出现：

• 为预发布或 CI 搭建一套结构——你想要空的表结构，好让测试能跑在真实的列、索引和约束上，但你绝对不想把几个 GB 的生产数据塞进一个用完即弃的环境。
• 只要种子数据——目标数据库里结构已经存在，你只需要 INSERT 行把它填满，而不要那些会和现有结构冲突的 CREATE 语句。
• 清除噪声——转储被 logs、sessions、audit_trail 或 cache 这类动辄几千万行、你从不想导入的表撑得臃肿不堪。

为什么 mysqldump --no-data 还不够

经典建议是 mysqldump --no-data（只要结构）或 mysqldump --no-create-info（只要数据）。这两个都是导出参数：它们改变的是一份从运行中的数据库新导出的转储包含什么。对于一份已经躺在磁盘上的 .sql 文件，它们无能为力。

实际情况里，文件往往是别人给你的，或来自某个备份任务，或来自一台你已无法在线访问的服务器。你没法对一个够不着的数据库重新跑 mysqldump——凭据没了、服务器下线了，或者这个文件本就是你手上仅有的东西。到这一步，那些参数毫无用处，你只能去编辑文件本身。

手动的办法

显而易见的动作是用 grep 或 sed 剥掉一些行。要保留结构、丢掉数据：

# 保留除 INSERT 行之外的一切
grep -v '^INSERT INTO' dump.sql > schema.sql

# 或者只保留 INSERT 行，得到一个仅含数据的文件
grep '^INSERT INTO' dump.sql > data.sql

这在一个小巧整洁的转储上看着没问题——然后在一个真实转储上崩掉：

• 多行 INSERT。单条 INSERT INTO … VALUES 可能跨越好几千行。grep 只匹配第一行，把其余的值都留成孤儿，生成一个损坏的文件。
• 扩展插入（extended insert）。mysqldump 会把许多行批量塞进一条巨型语句里。基于行的筛选根本判断不出这样一条语句在哪里结束。
• 注释和语句块。条件性的 /*! … */ 块、LOCK TABLES 和 -- 注释与数据交错在一起，于是一个天真的筛选要么留下垃圾，要么切掉导入所需的东西。
• 只要数据更糟。纯粹的 grep '^INSERT' 会把这些行所依赖的 SET 和 LOCK 语句扔掉，而任何没有正好从第 0 列开始的 INSERT 都会悄无声息地消失。

你最后是在调试自己写的筛选，而不是拿到你的表结构。

用 DumpCleaner 只留结构或只留数据

DumpCleaner 理解 SQL 语句，而不是逐行匹配，所以它能可靠地把结构和数据分开——在任意大小的文件上：

1. 把你的 .sql 转储拖入 DumpCleaner（MySQL、MariaDB 或 PostgreSQL）。它以流式解析文件，所以一个几 GB 的转储以恒定内存加载。
2. 切换你想要的语句类型：CREATE TABLE、CREATE INDEX、INSERT INTO、ALTER、DROP、LOCK、SET。取消勾选 INSERT INTO 就得到只含结构的文件；取消勾选 CREATE TABLE / CREATE INDEX 就得到只含数据的文件。
3. 或者选一个预设——仅结构或仅数据——一步设好每一个开关，随后如需要再逐表微调。
4. 导出。你得到一个精简的结构文件用于预发布或 CI，或一个干净的仅含数据的转储用于灌入种子数据。

由于筛选是语句感知的，一条多行的扩展 INSERT 会被整条保留或整条丢弃——绝不会从中间切开。

真正强大之处在于，筛选是按语句类型和按表进行的，而且二者可以组合。你可以保留每一张表的结构，却只为你确实需要的那三张表包含 INSERT 数据——把那张 8900 万行的 logs 表留成一个空壳。这是任何 --no-data 参数都表达不出来的。

常见问题