文小刚1. 项目核心思路与适用场景分析
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
1. 项目核心思路与适用场景分析
先说结论：瀚高数据库（HighGo Database）作为一款基于 PostgreSQL 内核的国产关系型数据库，它的数据导出 SQL 脚本工作，和传统 PostgreSQL 的思维模式高度一致，但又有几个地方和 MySQL、Oracle 的日常习惯不太一样。很多人第一次接手瀚高时，会下意识地去找“类 Navicat 的导出向导”，或者直接用 mysqldump 的惯性去敲命令，结果导出出来的 SQL 脚本要么在目标库跑不通，要么各种报错。这篇文章就是把瀚高数据库导出 SQL 脚本这件事从命令行到图形化，从单表到整库，从结构到数据，完整地梳理一遍。
先来界定一下“导出数据 SQL 脚本”到底覆盖哪些任务。我们日常说的导出 SQL 脚本，通常包含三种形态：
- 纯结构脚本：只有 CREATE TABLE、CREATE INDEX、CREATE SEQUENCE、COMMENT 等 DDL 语句，不含 INSERT 数据。
- 纯数据脚本：只有 INSERT INTO 或 COPY 语句，适合把 A 库数据搬到 B 库。
- 结构+数据脚本：DDL 和 DML 混合，一般用于快速重建一个环境。
瀚高数据库和原生 PostgreSQL 一样，自带一个功能非常强的逻辑备份工具 pg_dump（瀚高的命令行工具里也保留了同名命令）。这个工具解决的核心问题，就是“把数据库里的对象定义和数据，转成一份文本形式的 SQL 脚本”，好让你能在另一台机器、另一个版本、甚至另一种模式（比如瀚高的 MySQL 兼容模式）下把它恢复出来。和物理备份（直接拷贝数据文件）相比，SQL 脚本是平台无关、版本容忍度高、可读可编辑的，这也是它最适合做数据迁移、测试环境搭建、版本间数据归档的原因。
哪些人需要认真看这篇文章？我大致列一下真实场景：
- 运维人员要把瀚高生产环境的几张表导出，同步到测试环境或报表库。
- 开发人员本地用瀚高开发，需要把远程服务器上的表结构和基础数据拉到本地。
- 做数据迁移项目，需要把瀚高数据导出成 MySQL、Oracle 或其他库可兼容的格式，或者反过来把其他库的数据搬进瀚高。
- 需要为某个项目交付一份“数据库初始化 SQL 脚本”，打包进代码仓库，方便别人一键搭建环境。
涉及的核心关键词其实就是“瀚高数据库”“导出数据”“sql脚本”这三个，但真正在操作时，你会发现有一堆周边问题：字符集怎么定、自增序列怎么导出、外键顺序怎么处理、大字段怎么导出、导入时权限不够怎么办。这篇文章会把这些问题逐个拆开。
2. 命令行导出方案：hg_dump 与 pg_dump 的选型与参数解析
2.1 为什么瀚高也推荐使用 pg_dump 系列命令
很多人第一次接触瀚高时会有个疑问：瀚高不是国产数据库吗？为什么文档里到处是 pg_dump、psql 这种 PostgreSQL 的影子？原因是瀚高数据库的内核本来就源自 PostgreSQL，所以它的逻辑备份工具也继承了 PostgreSQL 的整套生态。你安装完瀚高数据库服务端之后，在 bin 目录下通常能看到这两个关键可执行文件：
- pg_dump：用于导出单个数据库的逻辑备份工具。
- pg_dumpall：用于导出整个数据库集群（包含所有数据库、角色、表空间）的脚本。
- psql：用于交互式执行 SQL 或导入 SQL 脚本的命令行客户端。
刚才提到的“hg_dump”或者说瀚高本身是否改了工具名，不同版本略有差异。有的版本叫 pg_dump，有的版本会在文档里写成 hg_dump，但本质上参数保持一致。我实际操作下来，最稳妥的做法是：直接在瀚高的安装目录 bin 下执行 pg_dump --version 看一眼，确认存在之后再用。不要凭印象在系统全局 PATH 里敲 pg_dump，那样很可能调到系统自带的 PostgreSQL 客户端，版本和库端不匹配时容易导出失败。
pg_dump 的核心设计思想很值得多说两句：它导出的不是数据库文件的二进制拷贝，而是重新生成数据库对象定义和数据所需的 SQL 语句。这种方式的优势很明显——文本文件可以用任意文本编辑器查看和修改，可以在不同小版本之间恢复，恢复时甚至可以指定只执行其中的一部分语句。缺点也很直接：恢复速度比物理备份慢，大库导出时占用的 IO 和 CPU 会比较高。但对于“导出 sql 脚本”这个需求来说，pg_dump 就是最合适的工具。
2.2 核心参数逐个拆解：从最简单到最常用
为了让大家既能快速上手，又能理解参数背后的原因，我把命令行导出的常用参数分成几组，每一组都配合实际场景来讲解。
第一组：最基本的连接参数。
bash复制pg_dump -h 192.168.1.100 -p 5866 -U highgo -d testdb -f /tmp/testdb.sql
- -h 指定数据库主机地址。默认是本地 socket 连接，远程导出时必须指定。
- -p 指定端口。瀚高数据库的默认端口通常不是 5432，安装时经常会配成 5866 或其他自定义端口，这一步特别容易踩坑。建议先看数据目录下的 postgresql.conf 或使用 psql 连接后执行 show port; 确认。
- -U 指定连接用户。瀚高默认的管理员用户常见为 highgo，安装时设置的密码对应的就是这个超级用户。
- -d 指定要导出的数据库名。
- -f 指定输出文件名。如果不加 -f，pg_dump 会把 SQL 直接打印到标准输出，你可以用重定向符 > 写入文件，效果一样。
第二组：内容范围控制参数。这是日常用得最多的部分，必须理解清楚。
| 参数 | 说明 | 经典使用场景 |
|---|---|---|
| -a | 只导出数据，不导出表结构、索引、序列等 DDL | 只同步数据到已建好表结构的目标库 |
| -s | 只导出结构，不导出数据 | 搭建空的测试环境或对比库表结构 |
| -t 表名 | 只导出指定的表 | 迁移某几张核心业务表时非常常用 |
| -T 表名 | 排除指定的表，导出其他所有表 | 排除日志表、临时表等数据量大的对象 |
| -n schema名 | 只导出指定 schema 下的对象 | 多 schema 数据库里只导业务 schema |
| -N schema名 | 排除某个 schema | 不导 pg_catalog 等系统 schema |
单独使用 -t 时支持通配符，比如 -t "public.log_*" 可以把所有以 log_ 开头的表一起导出。这里要注意，如果表名或模式名大小写敏感，需要在双引号里精确书写。
第三组：输出格式参数。pg_dump 支持五种输出格式，很多人只看文档没认真理解，这里对比一下：
- plain（纯文本 SQL）：默认格式，适合直接交给 psql 执行，也适合人工阅读和修改。
- custom（自定义归档格式）：二进制压缩格式，体积小，支持 pg_restore 选择性恢复，但不能直接用文本编辑器查看。
- directory（目录格式）：输出为一个目录，内部包含数据文件和 toc.dat 目录文件，适合超大数据库的并行导出和恢复。
- tar（归档格式）：和 custom 类似，但不支持压缩，也依赖 pg_restore。
- 注意：只有 plain 格式才是纯正的“SQL 脚本”，而 custom/directory/tar 是逻辑备份的归档格式，必须用 pg_restore 来恢复。很多新手以为导出的文件是 SQL，结果拿到一个 .dump 文件不知道怎么用。
对应的参数是 -F p / -F c / -F d / -F t。日常导出 SQL 脚本，用 -F p 即可，其他格式不在本文展开。
第四组：与数据内容相关的参数。
bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d testdb \
--inserts \