瀚高数据库导出SQL脚本全攻略：pg_dump命令详解与实战

在瀚高数据库上做数据迁移时，最常被同事问起的就是：导出数据到底怎么导，能不能直接给我一份 sql 脚本？这个需求听着很直白，真动起手来会发现里面藏着不少岔路。导全库还是导指定表，只要结构还是连数据一起给，是要拷到测试环境还是准备交付给第三方，命令和参数都不一样。我写这篇文章，就是把瀚高数据库导出 sql 脚本这个事从头到尾拆开讲，从最基础的 pg_dump 用法，到按条件导数据、跨库恢复、迁移到 MySQL 时需要改哪些内容，再附上我实际踩过的坑，适合刚接触瀚高数据库的 DBA，也适合那些被临时叫去导数的开发同学。

1. 先把“导出 SQL 脚本”这件事拆明白

1.1 最常见的三种导出需求

别看都是“导出数据”，实际落到工作里，大家真正要的东西往往分三类。

第一类是“整个库给我，我到另一边能原样重建”。这种一般发生在环境复制、灾备演练、项目交接场景。这种情况下不光要表里的数据，还要表结构、索引、约束、函数、触发器、视图、序列，甚至数据库的 owner 和权限都要一起过去。这是 pg_dump 最擅长的活，也是它能生成标准 sql 脚本的原因。

第二类是“只要几张表的数据，给我一份 insert 语句”。这个场景在开发联调、问题复现、给数据分析同事提供抽样数据时特别常见。你不可能把整个生产库都扔给对方，通常只想要一个业务相关的表，比如订单主表加订单明细表，数据量控制在可接受范围内，对方拿到之后能够直接执行。

第三类是“把历史数据从业务库导出来存档”。这类需求默认只导数据，不导结构，导出的脚本要能随时重新加载到另一个结构一致的表里。很多人一开始习惯用备份工具生成二进制文件，但真正用于归档交付的还是 sql 脚本更通用，因为它不依赖特定工具版本，拿个文本编辑器就能检查内容。

这三类需求对应的工具都是 pg_dump，但参数选择差异很大。如果一开始没搞清楚对方到底想要哪种结果，很可能导了半天，文件发过去人家跑不通，或者跑通了发现连索引都没带。所以我在导出前一定会追问一句：“这份数据最终要在哪执行，用什么用户执行，里面有没有敏感数据需要脱敏”。这几个问题比任何命令参数都能提前避免返工。

1.2 SQL 脚本、归档文件、COPY 文件怎么选

瀚高数据库的内核来自 PostgreSQL 生态，所以逻辑导出工具沿用了 PostgreSQL 的标准工具链。对于“导出 sql 脚本”这个需求，最核心的工具是 pg_dump，但 pg_dump 不止能输出一种格式，实际工作中至少会碰到三种结果。

第一种是默认的纯文本 sql 脚本，对应格式参数 -F p。这种文件是给人看的，里面有建表语句、建索引语句、数据插入语句。恢复的时候不需要 pg_restore，直接喂给 psql 执行就行。普通用户说的“给我一份 sql”，默认指的就是它。

第二种是自定义归档格式，对应 -F c。它本质上不是文本文件，而是压缩过的二进制格式，恢复时必须用 pg_restore。它的优势是恢复时可以灵活选择对象，比如想只恢复某一张表，用 pg_restore 直接指定表名就可以，不需要去改 sql 文本。但如果交付给一个只想要 sql 文件的人，这个格式没有意义。

第三种是纯数据文件，一般由 COPY 语句生成，比如 CSV、TXT。很多人不知道，默认纯文本 sql 脚本里，加载数据的核心其实也是一条 COPY 语句，并不是一条一条的 INSERT。这样设计是为了速度，COPY 导入比逐条 INSERT 快一个数量级。但对于不熟悉数据库的人来说，看到文件里一堆 COPY public.tb (col1, col2) FROM stdin; 会觉得奇怪，误以为这是没有导出成功。如果交付对象明确要求看到 INSERT 语句，可以通过 --inserts 或 --column-inserts 参数把数据改成显式插入。

从日常使用看，我一般默认导出纯文本 sql，文件后缀叫 .sql，如果后续需要精细恢复或者数据量特别大，再用 -F c。简单需求用简单工具，归档格式不到复杂场景不要硬上，否则自己也要承担更多的解释成本。

1.3 动手前先确认的四件事

没确认环境就执行导出命令，是很多事故的开端。我给自己定了个流程，每次导数据前先确认四个信息。

一是版本。瀚高数据库不同大版本对应的 PostgreSQL 内核版本不同，导出的 sql 脚本里可能包含针对特定版本才有的语法。导出端和导入端的版本差异太大时，容易出现脚本执行到一半报错的情况。最稳妥的做法是拿目标环境相同或更新的小版本去恢复，导出前先用 select version(); 看一眼内核版本。

二是账号权限。导整个库的结构信息，至少需要拥有该库的 CONNECT 权限，并且能读取系统表；如果要导出所有表的数据，账号需要对这些表有 SELECT 权限。很多时候你会碰到“有权限导出但没权限读取某几张表”的情况，最终生成的文件不完整却没有任何红色告警，等到目标库大量缺数据才发现问题。

三是端口和连接字符串。瀚高数据库默认端口在不同发行版本里并不完全一样，有些环境是 5866，有些沿用安装时的自定义端口，不要想当然。可以先用 psql -h 127.0.0.1 -p 5866 -U highgo -d postgres -c "select 1" 测试连通性，再执行导出。

四是导出文件落盘位置。如果服务器上 /tmp 空间不够，一根命令跑到一半磁盘写满，产生的文件既不能用于恢复，还会留下碎片。确认 df -h 有充足空间，再决定输出路径。特别是大库导出，输出文件经常是几个 GB，放根目录 / 下很容易翻车。

2. 命令行导出的核心工具与实操命令

2.1 pg_dump、pg_dumpall、psql 三兄弟各管什么

刚用瀚高数据库的人容易把导出工具的名字搞混，其实整套工具链就三样：pg_dump、pg_dumpall、psql。它们不是替代关系，而是配合关系。

pg_dump 负责导出单个数据库或其中部分对象，这是日常使用频率最高的工具。导出的结果可以包含结构和数据，也可以只选结构或只选数据。pg_dumpall 负责导出整个集群层面的东西，也就是所有数据库加上全局对象，比如角色和表空间。很多新人以为想备份整个实例要一个个库去 pg_dump，其实 pg_dumpall 一步就能把所有角色的定义拉出来，配合每个库的 dump 文件，才能在一台新机器上完整还原环境。

psql 不承担导出任务，它是执行 sql 的客户端工具，也是我们导入 sql 脚本时的主力。它支持元命令 \i，后面跟一个 sql 文件路径，就能在当前会话里逐条执行文件内容。命令行里也有 -f 参数，等价于启动后自动执行指定文件。

实际项目中，我极少单独使用 pg_dumpall 去导数据，因为它导出的是全实例对象，对单库迁移场景来说内容太重。正确做法是先用 pg_dumpall 把角色定义导出来，再逐个库用 pg_dump 导业务数据。尤其新环境建库时，如果没有先创建好原环境里的角色，后面恢复数据会报出一堆 role "xxx" does not exist 的错误，就是这一步没做。

2.2 全库导出一份可执行 SQL：最基础的一组命令

假设要导出的库名是 orderdb，用户是 highgo，环境 IP 是 127.0.0.1，端口是 5866。在能找到 pg_dump 的服务器上，执行下面的命令就能获得一份完整 sql 脚本：

bash复制/opt/HighGoDB/bin/pg_dump \
  -h 127.0.0.1 \
  -p 5866 \
  -U highgo \
  -d orderdb \
  -f /backup/orderdb_20250101.sql

如果已经配置了 PATH，可以直接写 pg_dump，不用全路径。命令执行后没有任何输出，不代表没有成功，需要用 ls -lh /backup/orderdb_20250101.sql 确认文件大小，再用 head -n 20 打开看头部内容。

这里有一个关键点：默认导出的 sql 脚本里，数据部分用的是 COPY 形式，不是常见的 INSERT。举个例子，导出文件里可能看到这样的内容：

sql复制COPY public.user_info (id, user_name, created_at) FROM stdin;
1	zhangsan	2024-06-01 10:00:00
2	lisi	2024-06-02 11:30:00
\.

如果交付对象明确说“我要的是 insert 语句”，那加上 --column-inserts 参数再导一份：

bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  --column-inserts \
  -f /backup/orderdb_inserts.sql

但要注意，改成 INSERT 后，脚本体积会显著变大，数据导入速度也会下降。一般来说，几个 GB 的数据表用默认 COPY 方式只需要几分钟，改成逐条 INSERT 可能要几十分钟甚至更久。所以我的建议是：本环境恢复用默认格式，跨系统交付且对方需要在可视化工具里手动执行时，才考虑生成 INSERT 风格的脚本。

2.3 表级、schema 级和按需排除导出

生产环境里，全库导出的机会远没有指定表导出多。比如开发要测试环境的数据，通常只要 orders 和 order_items 两张表，只需要在 pg_dump 后面用 -t 指定表名即可：

bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -t public.orders \
  -t public.order_items \
  -f /backup/order_tables.sql

这里的表名一定要带上 schema 前缀，写成 public.orders，不要只写表名。因为 pg_dump 解析表名时会根据 search_path 去找，不写 schema 容易定位错对象，或者报告找不到表。多个 -t 参数可以同时存在，导出结果里只包含这两张表的结构和数据，其他表一概不出现。

如果业务库按 schema 做了模块划分，比如 sales、inventory 两个 schema，想把其中一个模块全部导出来，用 -n 指定 schema：

bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -n sales \
  -f /backup/sales_schema.sql

反过来，如果整个库都要导，但明确排除某些日志表，这些表数据量大且没有迁移价值，使用 -T 排除：

bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -T public.access_log \
  -T public.slow_query_log \
  -f /backup/orderdb_no_log.sql

还有一类需求很常见：目标环境已经有完整的表结构，只需要往里面灌数据，这时候别把结构再导过去，否则会碰到表已存在、对象重复等一堆问题。用 -a 只导数据：

bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -a \
  -t public.orders \
  -f /backup/orders_data_only.sql

反过来如果只想拿结构，比如要把开发库的表结构同步给同事用，就加 -s。结构导出常用于版本对比和数据库设计评审，文件很小，阅读性也好。

为了看着方便，我把常用的参数整理成了速查表，贴在下面。

这张表不需要背，排障时拿出来对照即可。需要说明的是，-n 和 -t 不要混着用。因为 pg_dump 处理多个过滤条件时，对象可能因为同时满足 schema 和表条件而被重复导出，最终文件里出现重复对象。一个导出命令里要么以 schema 为粒度，要么以表为粒度，选一种方式走到底。

2.4 有条件的部分数据导出应该怎么做

pg_dump 命令和 MySQL 的 mysqldump 有一个明显不同，它原生没有提供“导出一张表中满足某个 where 条件的数据”这种简单参数。如果有一次只需要导出 created_at >= '2024-06-01' 的订单，该怎么办？

最简单粗暴但又很有效的方法，是先把目标数据落到一张临时表，再导出这张临时表。比如在源库执行：

sql复制create table public.orders_export as
select * from public.orders
where created_at >= '2024-06-01';

然后对 orders_export 这张表执行 pg_dump，导出完成后再把临时表删掉。这个方法思路清晰，缺点是会在源库产生实体表，对于不能随便建表的只读生产环境来说并不合适。

更推荐的做法是用 psql 把筛选结果直接处理成 INSERT 语句输出到文件。利用 quote_literal 能够安全地给字符串加引号，避免字段内容里带着单引号导致脚本语法错误。

sql复制select
  'INSERT INTO public.orders (id, order_no, user_id, created_at) VALUES (' ||
  id || ', ' ||
  quote_literal(order_no) || ', ' ||
  coalesce(user_id::text, 'NULL') || ', ' ||
  quote_literal(created_at::text) || ');'
from public.orders
where created_at >= '2024-06-01';

执行时用 psql 的无对齐输出模式，把结果重定向到文件：

bash复制psql -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -t -A \
  -f export_orders.sql \
  -o /backup/orders_filtered.sql

本地拼接出来的 INSERT 会成为最直接的 sql 文件。这种办法的数据量不宜太大，否则生成的文件行数会非常夸张，执行也慢。如果筛选出的数据量在百万行以下，这个方案完全够用；如果上千万行，那就别执着于 sql 文件了，直接导出 CSV 或先落到临时表再整体导出更合理。

3. 图形化工具、自动化执行与恢复

3.1 用 Navicat 连接瀚高并导出 sql

命令行虽好，但有些人就习惯图形界面操作，尤其是需要快速查看数据、手工指定几张表导出的场景。Navicat 本身并没有一个叫“瀚高数据库”的连接类型，但瀚高兼容 PostgreSQL 协议，所以打开 Navicat 后选择连接类型为 PostgreSQL，然后填写目标库地址、端口、账号、密码就能连上。

连接成功后，在左侧树形结构里找到需要导出的数据库，右键选择“转储 SQL 文件”，可以选“仅结构”或“结构和数据”。Navicat 生成的 sql 文件同样带有建表语句和插入语句，在数据量不大、表数量不多的情况下非常直观。有一点要注意，Navicat 生成的脚本在导入瀚高时，如果 sql 文件里包含反引号或者某些 MySQL 风格的语法，需要人工检查一下，因为两者对标识符的引号处理有差异。瀚高和 PostgreSQL 一样，标识符用双引号，而不是反引号。

Navicat 毕竟不是万能工具。我遇到过库里有几十张表，每张表几百万行数据，用图形界面整个导出，转了几十分钟还没反应，只能强制关闭。对于大数据量或严肃的备份恢复，命令行是更稳妥的选择。图形界面适合小数据量、结构简单、临时应急的场景，真遇到核心生产库迁移，我还是会回到 pg_dump。

3.2 用 Python 驱动做自定义导出的思路

需求稍微复杂一些，比如要遍历一个库里所有表，把每张表导成独立的 sql 文件，再做一个清单文件记录每张表的行数。这种需求用 pg_dump 也可以做，但是要自己写 shell 循环；相比之下，用 Python 会很自然。

瀚高兼容 PostgreSQL，所以 Python 端可以直接使用 psycopg2 或新版 psycopg 驱动连接。读取表名、表行数都不复杂：

python复制import psycopg2

conn = psycopg2.connect(
    host="127.0.0.1",
    port="5866",
    user="highgo",
    password="******",
    dbname="orderdb"
)
cur = conn.cursor()
cur.execute("""
    select tablename
    from pg_tables
    where schemaname = 'public'
      and tablename not like 'pg_%'
    order by tablename;
""")
tables = [row[0] for row in cur.fetchall()]
for table in tables:
    cur.execute(f'select count(*) from public."{table}"')
    table_count = cur.fetchone()[0]
    print(f"{table}: {table_count}")

这只是第一步。如果你需要把结果按表生成脚本，可以在 Python 里直接调用 COPY (SELECT * FROM ...) TO STDOUT，然后按行写入本地文件。比如导出 orders 表中某段时间的数据：

python复制with open("/backup/orders.csv", "w") as f:
    cur.copy_expert(
        "COPY (select * from public.orders where created_at >= '2024-06-01') TO STDOUT WITH CSV HEADER",
        f
    )

这种方式的优势在于，Python 可以无缝对接后续的数据处理。数据导出后你可以顺手做个行数校验、字段脱敏、文件压缩，或者直接把数据传到下游 Hadoop 环境做分析，逻辑都写在一个脚本里，可维护性比一堆临时命令好得多。不过要提醒一句，Python 脚本只能算辅助，不适合替代 pg_dump 去导出整套库结构，因为你很难把所有约束、注释、索引细节都复刻出来。

3.3 恢复 sql 脚本和批量执行的三种方式

导出只是前半段，把脚本在目标库执行成功才算完整。最常见的错误是把 sql 文件交给别人后，对方问“这文件我在哪打开跑一下？”我通常提供三种方式。

第一种是命令行直接执行，也是最推荐的方式。完整命令如下：

bash复制/opt/HighGoDB/bin/psql \
  -h 127.0.0.1 \
  -p 5866 \
  -U highgo \
  -d orderdb \
  -f /backup/orderdb_20250101.sql

这样 psql 会按顺序执行文件中的所有语句。执行过程中如果遇到语句错误，默认会继续执行还是终止，取决于是否在文件里设置了 ON_ERROR_STOP。我强烈建议手动加一个环境变量来控制：

bash复制psql -v ON_ERROR_STOP=1 -h ... -d orderdb -f dump.sql

这样一旦脚本中间出现任何错误，整个过程会停下来，避免后续语句在一个残缺状态下继续执行，产生更隐蔽的问题。

第二种方式是在 psql 交互会话里执行元命令 \i。比如已经进入了 psql，输入 \i /backup/orderdb_20250101.sql 就会执行整个文件，功能和 -f 基本一致。适合想边执行边观察的情况。

第三种方式是把多个 sql 文件合并成一个再执行。用 cat 或 tail 都行，但要注意文件之间可能有重复的 SET 语句和事务边界，合并后不一定会显著提高性能。如果脚本文件实在太多，也可以写一个简单的 shell 循环依次执行：

bash复制for f in /backup/sql/*.sql; do
    echo "executing $f"
    psql -v ON_ERROR_STOP=1 -h 127.0.0.1 -U highgo -d orderdb -f "$f"
    if [ $? -ne 0 ]; then
        echo "error at $f"
        exit 1
    fi
done

千万不要拿 DOS 窗口里的 sqlcmd 习惯往瀚高上套，sqlcmd 是 SQL Server 生态的命令，连不上 PostgreSQL 系数据库。脚本执行必须走 psql，或者像 DBeaver、Navicat 这类支持 PG 协议的客户端。

4. 导出的 sql 脚本里到底有什么，怎么改

4.1 脚本头部那串 SET 语句有什么作用

拿到一份 pg_dump 导出的 sql 脚本，打开文件后看到的往往不是直接建表，而是一堆很像配置文件的内容。这很容易让人误以为文件坏了，其实那些是恢复脚本运行环境的关键设置。以一段常见头部为例：

sql复制--
-- PostgreSQL database dump
--

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

statement_timeout = 0 表示执行语句不设超时。如果某条语句运行时间超过默认业务超时阈值，会被数据库强制取消，导致恢复中断，所以备份脚本要显式把它设为 0。client_encoding = 'UTF8' 设置客户端编码，保证脚本里的中文、特殊字符不会变成乱码。standard_conforming_strings = on 是按 SQL 标准处理字符串中的反斜杠。search_path 的设置比较关键，它会让脚本里的对象名不受客户端默认 search_path 影响，防止导入时找错 schema。check_function_bodies 设置为 false，是为了在创建函数时不立即校验函数体引用的对象是否存在，因为表可能还没创建，先允许函数建立。

这些参数如果你完全不理解，其实也不影响正常执行。但如果脚本执行中报了一些奇怪的错，比如“timestamp out of range”或者“function does not exist”，回头检查头部的设置往往能找到线索。

4.2 建表顺序、外键、序列对象为什么那么乱

细心的读者可能会发现，导出的脚本不是按照我们脑子里“建表、加注释、加索引、导数据”的顺序来排的。pg_dump 有自己的对象排序逻辑，它首先要保证对象之间最基本的依赖关系成立，但外键约束却被往后放了。原因是外键依赖其他表的主键，只有相关表都完成数据加载后再去创建外键，才能避免因为数据加载顺序导致的外键冲突。

脚本尾部你经常会看到类似下面的语句：

sql复制ALTER TABLE ONLY public.orders
    ADD CONSTRAINT orders_user_id_fkey FOREIGN KEY (user_id) REFERENCES public.user_info(id);

这是把外键约束放在所有数据导入之后才添加。这种设计是合理的，因为在导入过程中，如果源库和目标库的数据并不是严格一致，先加外键会导致批量导入报错。所以不要把脚本里的语句顺序随意打乱，尤其是不要为了“看起来干净”把所有 ALTER TABLE 语句提到数据导入之前。

序列的导出也值得一提。瀚高里自增字段通常依赖序列，导出脚本时 pg_dump 会把序列的当前值单独设置一下，常见形式是：

sql复制SELECT pg_catalog.setval('public.orders_id_seq', 10001, true);

这个语句很重要。如果你恢复后没有执行它，新表里主键从 1 开始自增，但表里已经有历史数据，马上就会碰到主键冲突。正常执行完整脚本时不会漏掉这一步，但如果有人只摘取其中一部分 insert 执行，就很容易漏掉序列调整，这属于常见事故点。

4.3 换环境恢复前，脚本里这些内容必须改

一旦 sql 文件要换到另一个数据库环境里去执行，直接原样跑经常会失败。遇到最多的一个问题是什么？owner 不存在。源库里的表 owner 是 order_owner，目标环境里可能压根没这个用户。解决办法有两种：导出时加 --no-owner，脚本里就不会生成 OWNER TO 语句，对象默认归执行用户所有；如果脚本已经导出来了，也可以用非交互的文本替换，把所有匹配到的 owner 改成目标用户。

另一个常见问题是 schema 名不同。源库用的是 public 还好，如果业务自己建了一个 biz schema，目标库只有 public，直接执行会报 schema "biz" does not exist。这种问题没有无脑替换的万金油办法，必须先确认目标库里建好对应的 schema。文档里那些依赖 schema 的视图、函数，如果 schema 对不上，恢复过程会报出一长串错误。

还有权限语句值得注意。导出脚本如果有大量的 GRANT 语句，目标环境的角色清单不一致时，也会报错。大部分情况下，普通迁移不必要把源库权限体系原封不动搬过去，加 --no-privileges 跳过授权语句，反而能让脚本跑得更顺利。

如果脚本需要给其他团队执行，我建议在文件开头加一段中文注释，把执行前需要具备的条件写清楚。比如目标库已创建、字符集为 UTF8、需要具备创建扩展权限。这不是数据库知识，但非常实用，能避免恢复过程中反复来回沟通。

4.4 目标环境是 MySQL，或者要兼容 MySQL 怎么做

瀚高数据库里有一个被频繁搜索的场景是“切换到 MySQL 模式”，这通常发生在企业从 MySQL 整体迁移到瀚高，或者反过来需要把数据同步回 MySQL 的场景。要明确一点：不同版本瀚高对这类的兼容支持程度不一样，启用方式也可能不同，有的通过初始化参数，有的在创建数据库时指定。动手前一定先看官方文档，确认当前版本的能力边界。

如果把一份由 pg_dump 导出的 sql 脚本直接丢给 MySQL 执行，大概率跑不通，原因集中在几个地方。

对象引用方面已经不止一次提到，瀚高默认使用双引号做标识符引用，MySQL 默认用反引号。如果脚本里出现 CREATE TABLE "public"."user_info"，MySQL 会把双引号内容当字符串处理，根本建不出表来。导出前如果知道目标是 MySQL，就应该先规划好是否可以把表名规则统一成小写、不加前缀，省去后续替换的麻烦。

数据类型方面也要格外留意。瀚高里的 boolean 在 MySQL 中一般要用 tinyint(1) 替代；timestamp with time zone 在 MySQL 里通常要降级成 timestamp 或 datetime。serial 自增主键在 MySQL 里要换成 auto_increment；uuid 类型如果没有对应，可能要转成 char(36)。

如果目标环境本身就是瀚高且已切换到 MySQL 兼容模式，那么导出脚本之前应该先确认当前兼容模式下支持哪些类型和语法。不要指望一个模式开关能解决所有兼容问题，脚本里涉及函数、存储过程的代码还是需要逐一调整。我的经验是，跨数据库迁移不要试图做到“一条 sql 脚本包打天下”，更合理的方式是先做结构迁移，再做数据迁移，数据量小可以用 INSERT 脚本，数据量大就采用 CSV、文本文件加导入工具的路径。

5. 常见报错和我的排查习惯

5.1 高频报错速查表

把实际导数据过程中最容易踩的坑整理成了一张表，每条都是真金白银换来的经验。

排查顺序也有讲究，建议按“网络、认证、库是否存在、schema 是否正确、表名是否限定、权限是否足够”这个顺序来查。很多初学者在连接报错时就开始研究账号权限，其实最可能的问题就是端口写错了或者防火墙没放行。先确认最底层、最简单的连接因素，比一头扎进复杂问题要高效得多。

5.2 一次真实的数据导出恢复过程复盘

上个月我就帮同事把一个测试库的 orderdb 导到新开的预发环境。当时的需求是复制一套结构加全部数据，让预发环境的接口能用真实数据联调。整个过程按多步走，我复盘一下细节。

第一步，在源库统计关键表行数，并生成一份校验基准。我执行了一个查询，把 public schema 下用户表的行数列出来存到文件里，这一步花不了几秒，但事后能用来确认数据完整。

第二步，执行全库导出：

bash复制pg_dump -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -f /backup/orderdb_pre.sql

导出文件有 1.8GB，用时约三分钟。文件大小正常，没有中断，我再打开文件末尾确认有 COMMIT; 完成标记，才敢认为导出没有半途损坏。

第三步，到目标库先做全局对象准备。因为目标环境和源环境账号体系不同，我用 --no-owner --no-privileges 思路去恢复，先不纠结权限。目标库本身已经存在，就不需要执行 CREATE DATABASE，否则还得去改脚本里的建库语句。

第四步，执行恢复：

bash复制psql -h 127.0.0.1 -p 5866 -U highgo -d orderdb \
  -v ON_ERROR_STOP=1 \
  -f /backup/orderdb_pre.sql

执行过程比较安静，中间只出现几条关于扩展的提示，因为目标库没预先安装某个扩展，我在目标库以超级用户执行了 CREATE EXTENSION 后重新跑。恢复时间约八分钟，脚本最后正常完成。

第五步，最关键的数据行数校验。在目标库重新执行一次行数统计，和第一步的记录对比。主表数字一致，但某个明细表少了三千多行。原因很快定位到恢复早期源库业务人员还在持续写入数据，因为我没有在导出前对源库做只读锁定。理论上可以选择在业务低峰期导出，或者在导出开始前先停掉写入任务。这次虽然差异不大，但也算给我提了个醒，凡是做这类拷贝，导出的时间点必须明确，并在完成后再次核对最新行数，而不是拿导出一小时前的统计结果当基准。

5.3 强制校验导出数据完整性的几个习惯

行数校验是最直观的方式，但如果只靠行数其实不够。有些场景，字段级的数据可能因为字符集或类型转换出了问题，行数完全一致但内容不对。所以我还养成了几个额外的检查习惯。

先看文件结束标记。纯文本 sql 脚本正常结束时，末尾一定有一条 COMMIT;。pg_dump 会默认将整个导出过程包在一个事务里，所以文件的结尾如果缺失 COMMIT，说明这个文件极可能是在导出过程中中断的，不能交付。用一行命令就能快速检查：

bash复制tail -n 5 /backup/orderdb_pre.sql

再看敏感字符是否异常。如果导出文件包含大量中文数据，打开文件时如果看到一堆 \xxx 形式的转义或明显的乱码字符，就要警惕源库和目标库字符集是否一致。瀚高通常建议 UTF8，不建议用 SQL_ASCII，因为 SQL_ASCII 下很多客户端字符集转换会失效，数据跨环境后容易出乱码。

最后做一个随机抽样。不要只看总数，随机抽一条业务主键进行对比。比如取一个订单号，在源库和目标库分别执行查询，比对关键字段的值。这个方法看起来原始，但对发现数据库兼容问题非常有效。一次数据迁移，表和索引都建好了，如果客户名称字段出现半个汉字的截断，行数再多也是白白搬了一遍错误数据，这个坑靠统计行数是查不出来的。

这些习惯没有一个是高深的操作，但都能在问题扩大之前暴露异常。导出不是把命令一敲就完事，校验环节占整个工作量的比重并不小。我也是吃过几次亏之后，才真正重视起这一步。