从PostgreSQL的pg_dump备份中恢复单张表并不复杂，但实际场景中目标库的表结构往往与备份时刻不同：可能增加了几列、删除了旧约束，或者索引已经重新设计。此时如果不加限制地执行pg_restore，归档里的CREATE TABLE语句就会把现有表结构覆盖掉。要解决这个问题，核心思路就是让pg_restore跳过模式对象，只执行数据导入部分。本文以自定义格式备份为例，详细说明如何只恢复表中的数据，同时保留目标库现有的表定义、约束和索引。
下文涉及的命令默认在PostgreSQL 12及以上版本中测试通过，但pg_restore的参数行为在更早版本中基本一致。如果你使用的是SQL格式备份，情况会有所不同，后面也会单独说明。
一、pg_restore恢复机制与重建模式的根源
pg_restore处理的归档文件并不是简单的SQL文本，而是一个带目录信息的备份文件。使用pg_dump -Fc生成的custom格式或-Fd生成的directory格式时，pg_restore会读取归档中的TOC（目录），里面按顺序记录了各类数据库对象：SCHEMA、TABLE、SEQUENCE、TABLE DATA、CONSTRAINT、INDEX等。执行pg_restore时如果不加参数，它会根据TOC依次恢复这些对象，先建表再导入数据，最后创建约束和索引，因此自然会重建模式。
要让pg_restore跳过模式部分，最直接的参数是--data-only，可简写为-a。这个参数会忽略归档里的CREATE语句、ALTER语句等模式变更，只执行数据加载部分。然而仅使用--data-only还不够，因为备份文件往往包含多张表，pg_restore会尝试恢复所有表的数据。如果目标库里某些表不存在，或者你只想恢复其中一张表的数据，就需要再加上--table参数进行过滤。--table可以多次使用，也可以使用schema.table形式，只选中与指定表相关的数据条目。
这里有一个容易忽略的点：--table参数只有在归档格式为custom或directory时才有效。对于pg_dump生成的普通SQL脚本文件，pg_restore无法解析其内部结构，也就不能使用--data-only和--table来精确控制。因此，如果希望灵活地只恢复数据，备份时应优先选择custom格式或directory格式。
二、完整操作流程：备份单表与恢复数据
先看备份环节。假设源库中有一张订单表public.orders，我们需要把它的数据单独导出，同时保留后续精准恢复的能力。使用pg_dump的自定义格式：
pg_dump -Fc -t public.orders -f C:\backups\orders.dump mydb
这里-Fc表示生成custom格式归档，-t指定只导出public.orders表，-f指定输出文件，最后是数据库名。归档中会包含这张表的模式定义、数据、以及与之关联的约束、索引和序列等。如果是在Linux环境，文件路径可以写为/backups/orders.dump。关键点是必须使用-Fc或-Fd，不能使用默认的纯文本格式，否则后面pg_restore的过滤能力会失效。
恢复时，在目标库上执行：
pg_restore --data-only --table=public.orders -d targetdb C:\backups\orders.dump
这个命令会打开归档，只选择public.orders表的数据部分，将其通过COPY语句导入到targetdb数据库。因为使用了--data-only，归档中的CREATE TABLE、CREATE INDEX等模式对象会被跳过，目标表如果已经存在就不会被重建。不过，这要求目标表的结构与备份数据兼容。pg_restore执行COPY时是按列位置进行匹配的，列数量和数据类型需要一致。如果目标表比备份时多出一些带默认值的列，通常可以成功；但如果缺少某些列，或者列类型发生变化，COPY会直接报错。
为了确认导入的结果，可以在恢复前后分别执行pg_restore -l C:\backups\orders.dump来查看归档内容。该命令列出TOC中的所有条目，其中TABLE DATA对应的项就是实际会被导入的数据。你可以看到在--data-only模式下，其他条目将会被忽略。
三、处理约束、触发器和序列值
即使只导入数据，也可能受到目标库约束和触发器的影响。例如外键约束会检查引用的完整性，如果导入顺序不当或者相关表数据尚未恢复，就会出现violates foreign key constraint错误。对于单表数据恢复，外键通常不是大问题，但如果备份涉及多张表，建议在恢复会话中临时关闭触发器。pg_restore提供了一个--disable-triggers参数，但它需要以超级用户身份连接，并且会关闭目标表的触发器后导入数据，完成后再重新启用。使用方式如下：
pg_restore --data-only --table=public.orders --disable-triggers -d targetdb C:\backups\orders.dump
另一种更细粒度的方法是使用会话变量session_replication_role。当它的值设为replica时，普通触发器和规则不会触发，只有标记为ENABLE REPLICA或ENABLE ALWAYS的触发器才会执行。这个变量通常用于逻辑复制，也可以手动设置来绕过触发器。由于pg_restore是外部进程，可以通过PGOPTIONS环境变量注入该设置：
PGOPTIONS="-c session_replication_role=replica" pg_restore --data-only --table=public.orders -d targetdb C:\backups\orders.dump
在Windows下需要调整环境变量设置方式，但原理相同。导入完成后，触发器会自动恢复为原状态，因为该设置只影响当前连接。需要注意的是，session_replication_role=replica并不会绕过外键约束，外键仍然会正常检查。如果外键确实影响导入，需要先删除或临时禁用相关约束，或者确保依赖数据已经存在。
序列值回填是另一个容易被忽略的问题。pg_dump在备份表时，如果表中有serial或identity列，归档里会包含对应的SEQUENCE对象及其setval调用。在--data-only模式下，pg_restore默认会尝试恢复序列值，但前提是目标库中存在对应的序列对象。如果你在目标库中已经重建了序列，类型和名称都能对应，则不会有问题；如果目标库的结构由其他迁移工具管理，序列可能有不同名称或不存在，此时恢复序列值的操作会失败。可以通过添加--no-owner和--no-privileges来排除所有权和权限，但并不能跳过序列值设置。要跳过setval，可以使用pg_restore的--use-list或手动列出TOC并排除相关条目，不过对于单表恢复，通常目标表已经存在，序列值可以在数据导入后手动通过setval调整。
四、SQL格式备份的替代方案
前面提到，普通SQL格式的备份无法使用pg_restore的--data-only和--table过滤。如果你手里只有SQL备份文件，或者希望更灵活地控制导入哪些列，可以改用pg_dump的--column-inserts或--inserts选项重新生成数据脚本。命令如下：
pg_dump --data-only --column-inserts -t public.orders mydb > orders_data.sql
这条命令生成的文件只包含INSERT语句，没有CREATE TABLE，因此恢复到目标库时不会重建表结构。--column-inserts会为每一行数据生成带列名的INSERT语句，而不是默认的COPY格式。这样的脚本即使目标表列顺序不同，只要列名存在，也能正确导入。缺点是生成的SQL文件会大很多，且导入速度比COPY慢，适合数据量较小的场景。如果数据量较大，可以去掉--column-inserts，使用COPY格式的--data-only导出，但那样就需要保证目标表列位置完全一致。
拿到orders_data.sql后，可以直接用psql导入：
psql -d targetdb -f orders_data.sql
如果SQL文件中包含SET search_path或者SET statement_timeout之类的命令，可以保留，也可以手动编辑。重点在于这个方案完全不涉及模式恢复，目标表结构由DBA控制，数据只是以普通INSERT或COPY方式写入。对于需要做列级调整的情况，可以先对SQL文件进行文本替换，比如修改表名或者过滤某些列，因为它是纯文本格式。
需要提醒的是，如果备份来自pg_dump的默认纯文本格式，它同时包含模式和数据，直接执行会重建表。要这种情况下只取数据，可以先用文本编辑器或grep工具提取INSERT或COPY相关部分，但这种方法容易遗漏依赖和转义规则，不建议在生产环境使用。更好的做法是重新执行pg_dump，指定--data-only和-Fc，生成可用于精准恢复的归档文件。
五、常见错误排查
恢复表数据时最常见的报错是relation "public.orders" does not exist。这说明目标库中还没有这张表，或者--table参数没有正确匹配。pg_restore的--table参数匹配的是对象名，默认区分大小写并可能需要使用引号来处理大小写敏感的表名。先检查目标表是否存在，再确认参数中写的是schema.table格式，不要只写表名。
另一个高频错误是COPY失败，提示列数量不匹配。因为pg_restore在--data-only模式下从归档直接读取COPY数据流，列顺序严格执行。此时要么调整目标表结构与备份一致，要么改用--column-inserts方案重新生成SQL脚本。绝不能在pg_restore命令中通过指定列名来映射，它不支持这种操作。需要列级灵活性时，SQL格式配合INSERT语句是更合适的选择。
权限不足也会导致失败。--disable-triggers要求连接用户是超级用户，如果用户没有相应权限，pg_restore会报错。不要为了省事在生产环境直接用postgres超级用户执行所有操作，可以只对需要关闭触发器的表进行授权，或者使用PGOPTIONS绕过触发器而不要求超级用户（仍需有表写入权限）。导入完成后，务必确认触发器已经恢复，避免后续业务操作在无触发器保护的情况下写入数据。
pg_restorePostgreSQL数据恢复修改时间：2026-09-28 11:54:39