PostgreSQL从10版本开始引入逻辑复制，其核心是通过发布（Publication）定义哪些表的变更需要被复制，订阅（Subscription）则负责消费这些变更并应用到目标库。行级过滤在早期的逻辑复制中仅支持在订阅端通过创建带WHERE条件的同名表或触发器来间接实现，这种模式会把过滤逻辑分散到每个下游节点，且无法阻止不必要的数据从发布端流出。从PostgreSQL 15开始，发布端原生支持行过滤表达式，使得过滤策略可以集中在发布端统一管理，这从根本上改变了逻辑复制的配置思路。

分散式过滤配置的常见问题

在PostgreSQL 15之前，如果只想复制表中满足特定条件的行，常见的做法是在订阅数据库上创建一张结构与源表相同但带WHERE条件的普通表，并配合逻辑复制的初始数据同步机制。但逻辑复制应用进程只会将数据写入与发布表同名的目标表，订阅端并不会自动应用行过滤。因此，实际项目中往往采用更复杂的变通方案：在发布端将数据按过滤条件拆分到不同分区，每个分区作为独立的表发布；或者使用pglogical等第三方扩展提供的行级过滤功能。这些方案都意味着过滤逻辑被分散到表结构或扩展配置中。

分散式配置带来的问题非常明显。第一，当订阅数量增加时，同一个业务过滤条件需要在多个订阅节点重复维护，容易出现不一致，例如一个订阅漏改了条件，就会复制出错误的数据集。第二，过滤条件调整的变更流程复杂，需要同时修改多个目标库的表结构或触发器定义，难以做到原子性。第三，发布端无法感知下游需要哪些行，所有变更都会进入逻辑复制流，造成网络带宽和订阅端处理资源的浪费。第四，审计层面缺乏单一事实来源，排查复制数据不准确的问题时，需要在多个节点之间比对过滤规则。

以一个电商订单表为例，假设总部需要将不同区域的订单分发到对应的区域数据库。在分散式方案中，每个区域库都要创建一张带region条件的目标表，如果区域划分发生变化，就需要逐一调整所有区域库的表定义。一旦某个区域库未及时更新，就可能复制到不属于该区域的数据，带来数据泄露风险。

集中式过滤策略的实现方法

PostgreSQL 15引入的发布端行过滤功能，允许在创建或修改发布时，为每张发布表指定一个WHERE条件。语法如下所示：

-- 创建带行过滤的发布
CREATE PUBLICATION pub_orders_filtered
FOR TABLE orders
WHERE (status = 'active');

该条件会在逻辑解码输出插件生成变更流时生效，不满足条件的行根本不会进入复制协议。这意味着过滤逻辑只需在发布端维护一次，所有订阅该发布的节点都会自动获得相同的行集。如果需要修改过滤条件，可以使用如下命令：

-- 修改已有发布的行过滤条件
ALTER PUBLICATION pub_orders_filtered
SET TABLE orders
WHERE (status = 'active' AND region IN ('north', 'east'));

需要注意的是，修改发布表的WHERE条件不会自动重新同步已有数据。例如之前已经复制到订阅端的行，在条件变更后可能不再满足新的过滤条件，但这些行仍会保留在订阅端，除非手动清理或重新初始化订阅。因此，在实际操作中，应当将过滤条件变更视为一次需要重新同步的数据迁移流程，而不是简单的在线调整。

除了直接使用WHERE条件，分区表也是实现集中式过滤的另一种有效手段。通过将数据分散到不同的分区，并只发布满足特定条件的子分区，可以在结构上固化过滤规则。PostgreSQL允许设置publish_via_partition_root参数来控制发布父表时是否按分区根表发布。例如：

-- 创建分区表
CREATE TABLE orders (
    id bigint,
    region text,
    status text,
    created_at timestamp
) PARTITION BY LIST (region);
CREATE TABLE orders_north PARTITION OF orders FOR VALUES IN ('north');
CREATE TABLE orders_south PARTITION OF orders FOR VALUES IN ('south');
-- 只发布北方区域的分区
CREATE PUBLICATION pub_orders_north
FOR TABLE orders_north;
-- 或者发布父表，但通过publish_via_partition_root控制
ALTER PUBLICATION pub_orders_all SET (publish_via_partition_root = true);

分区方案的优点在于过滤条件与数据物理分布一致，性能可预测，且容易进行分区级别的备份和恢复。但它的灵活性不如WHERE表达式，当过滤条件频繁变动或需要跨多个维度组合时，分区维护成本会显著上升。因此，集中式过滤策略的选型需要综合考虑过滤条件的稳定性、数据量和运维复杂度。对于大多数场景，发布端WHERE条件已经能够满足需求，并且是实现真正集中式管理的首选。

还需要注意，发布端行过滤表达式支持普通的比较运算符、逻辑运算符以及部分内置函数，但不允许使用易变函数（如random()、now()）和子查询。如果过滤条件中包含这些不受支持的元素，创建或修改发布时会直接报错。此外，被过滤的行虽然不会出现在逻辑复制流中，但相关的WAL记录仍然会保留在发布端，因此复制槽的WAL保留策略不会因为行过滤而减少，仍需要合理监控WAL增长。

集中式过滤策略的性能影响与实施建议

从性能角度看，发布端行过滤的主要开销发生在逻辑解码的输出插件阶段。在解码事务时，需要针对每一条变更记录评估过滤表达式，如果表达式简单且索引支持良好，额外开销通常很小，远低于将全量数据发送到订阅端再过滤的成本。如果过滤条件涉及多个字段或需要类型转换，发布端的CPU消耗会相应增加，但相比网络传输和订阅端写入，仍然具备明显优势。为了量化这一差异，可以在测试环境中分别测量启用过滤和未启用过滤时的复制延迟及发布端CPU使用率，选取合适的表达式复杂度。

集中式过滤策略在生产环境落地时，建议遵循以下流程。首先，梳理所有订阅节点对数据子集的需求，将过滤条件抽象成一组版本化的SQL脚本，纳入代码仓库管理。其次，在发布端创建或修改发布时，先在测试环境验证过滤后的行集是否符合预期，并确认订阅端数据一致性。第三，对于已有数据的订阅，如果要更改过滤条件，应先评估是否需要重新初始化订阅，或者采用增量同步方式迁移不符合新条件的存量数据。第四，建立监控告警，关注逻辑复制延迟、发布端WAL堆积以及订阅端冲突，尤其当过滤条件涉及主键或外键关联字段时，要确保目标库的引用完整性不会因缺失某些行而被破坏。

一个常见的错误排查场景是：修改了发布端的WHERE条件后，订阅端数据没有发生变化。此时需要检查发布定义是否真的被应用到了正确的表上，可以通过查询pg_publication_rel系统视图来确认：

SELECT p.pubname, c.relname, pr.prqual
FROM pg_publication_rel pr
JOIN pg_publication p ON p.oid = pr.prpubid
JOIN pg_class c ON c.oid = pr.prrelid
WHERE p.pubname = 'pub_orders_filtered';

其中的prqual列会显示每个表的过滤表达式。另外，如果订阅端之前已经存在部分数据，而新的过滤条件排除了这些行，它们并不会被自动删除，这属于预期的行为，但很容易被误认为过滤没有生效。因此，在变更过滤条件时，必须在操作文档中明确说明存量数据的处理方式，避免产生数据不一致的误解。

总结来说，PostgreSQL逻辑复制的过滤策略从分散走向集中，核心在于合理利用发布端行过滤能力，并配合分区表及严格的变更管理流程。集中式方案不仅降低了多订阅环境下的运维复杂度，还提升了复制效率和数据安全性。对于正在规划或已经使用逻辑复制的团队，建议尽快将过滤规则迁移到发布端，统一管理，为后续扩展订阅规模打下良好基础。