当PostgreSQL数据库的体积增长到几百GB甚至TB级别时，直接执行一条pg_dump命令进行全量导出，经常会遇到各种意料之外的状况：磁盘空间被单个巨型文件占满、导出过程持续数天后网络中断导致前功尽弃、单线程导出速度慢到无法接受。这时候就需要换一种思路，把整个导出任务拆分成多个可管理的小块，也就是所谓的分段策略。本文将从pg_dump的底层机制入手，逐一分析几种实用的分段导出方案。
先搞清楚pg_dump的两种输出格式，选错格式一切白费
很多刚接手大库迁移的人习惯性地使用默认的纯文本格式导出，也就是不加任何参数直接执行pg_dump。这种格式会把整个数据库生成为一个大SQL脚本文件，文件里是一条条INSERT或COPY语句。问题在于，纯文本格式不支持并行导出，也不支持选择性恢复，一旦生成，你只能完整地导入整个文件，中途想跳过某张表都做不到。对于超大库来说，这种格式基本可以判定为不可用。
正确的选择是自定义格式或目录格式。自定义格式通过-Fc参数指定，生成一个压缩过的归档文件，配合pg_restore可以按需恢复任意对象。而目录格式通过-Fd参数指定，会把导出内容拆成多个文件放在一个目录里，每张表一个文件，天然就是分段存储。更重要的是，目录格式是唯一支持并行导出的格式，配合-j参数可以启动多个工作进程同时导出不同的表，速度提升非常明显。下面的命令展示了目录格式加并行的基本用法：
# 使用目录格式并行导出，4个并行任务 pg_dump -h 127.0.0.1 -U postgres -Fd -j 4 -f /data/backup/mydb_dump mydb # 导出完成后目录内结构大致如下 # mydb_dump/ # ├── toc.dat # ├── 3050.dat.gz （某张表的压缩数据） # ├── 3051.dat.gz # └── restore.sql
目录格式下的每个数据文件默认使用gzip压缩，压缩比通常能达到原始体积的三分之一到五分之一，这对磁盘空间的节省相当可观。如果服务器CPU资源充裕，还可以指定-Z参数调整压缩级别，压缩级别越高文件越小但CPU消耗越大，需要根据实际情况权衡。对于网络传输场景，可以考虑去掉压缩改成外部压缩工具处理，或者直接在目标端边传输边恢复，避免落盘中间文件。
按表和模式拆分：把一个大任务切成多个独立小任务
并行导出解决的是速度问题，但如果连导出的整体过程都不允许长时间占用资源，或者需要分批次在维护窗口内完成，就必须手动按表或按模式拆分。pg_dump提供了-t参数导出指定的表，-n参数导出指定的模式。一个常见的做法是先梳理出库内所有大表和普通表，把普通表和表结构定义放第一批导出，大表再按体积排序逐张或逐批导出。查询表体积可以使用下面的SQL：
-- 按体积倒序列出前20张表，单位MB
SELECT relname AS table_name,
pg_total_relation_size(relid) / 1024 / 1024 AS size_mb
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;
拿到表清单后，可以写一个简单的脚本循环导出，每张表一个独立文件，任何一张表导出失败都不影响已完成的成果，重试成本极低。这种按表拆分的方式还有一个隐藏好处：如果某张表因为数据损坏导致导出中断，问题范围被隔离在单张表内，排查起来非常直接。
#!/bin/bash
# 按表循环导出脚本示例
TABLES="orders order_items payments users logs"
for t in $TABLES; do
echo "导出表: $t"
pg_dump -h 127.0.0.1 -U postgres -Fc \
-t "$t" -f "/data/backup/table_${t}.dump" mydb
if [ $? -ne 0 ]; then
echo "表 $t 导出失败，记录日志后继续"
echo "$t" >> /data/backup/failed_tables.txt
fi
done
需要注意的是，按表拆分时序列、视图、函数、触发器这些非表对象要单独处理一次。可以在第一批导出时加上--schema-only参数把全部对象定义导出来，恢复时先导入结构再导入各表数据，最后重建索引和约束。顺序搞反了会导致恢复时主键冲突或外键校验失败。
利用排除规则和快照一致性，保证分段导出数据完整
分段导出最大的隐患是一致性问题。如果第一次导出在晚上八点开始，第二次导出在第二天凌晨进行，期间业务数据持续写入，两批文件拼起来的数据就是错乱的。解决这个问题有两种思路。第一种是让应用停止写入或者切换到只读模式，适合允许短暂停机的场景，最简单可靠。第二种是使用快照，在支持快照的文件系统或存储层先做一份磁盘快照，然后针对快照内容做分段导出，这样所有批次看到的数据都是同一时刻的版本。
如果既不能停机也没有快照条件，可以借助复制槽搭建一个临时的流复制从库，从库上跑pg_dump导出任务，主库业务完全不受影响，从库本身的数据天然是一致的。这是生产环境处理超大库迁移的主流做法。此外，pg_dump的排除参数在精细化控制时非常好用，-T可以排除指定的表，-N可以排除指定的模式，配合通配符能灵活地圈定导出范围：
# 导出除日志类表之外的所有业务表
pg_dump -h 127.0.0.1 -U postgres -Fc \
-T "log_*" -T "tmp_*" \
-f /data/backup/business.dump mydb
# 只导出public模式下的表结构，不带数据
pg_dump -h 127.0.0.1 -U postgres --schema-only \
-n public -f /data/backup/schema_only.dump mydb
分段导出完成后，恢复端同样要用并行方式来提速。pg_restore的-j参数可以并行恢复多个表数据，配合前面目录格式的导出文件，导入速度可以提升数倍。建议恢复时先加--section=pre-data和--section=data分阶段执行，最后再跑--section=post-data重建索引，因为先导数据后建索引比带着索引写数据快得多。整套流程跑通后，原本需要几天时间的超大库迁移，通常可以压缩到几个小时以内完成，而且每个环节失败后都可以从断点继续，不再是一次失败全部重来。