PostgreSQL逻辑复制基于发布与订阅模型，发布端将指定表的变化通过逻辑解码转换为数据流，订阅端应用这些变化。过滤策略让发布不再是全表复制，而是按条件只发布部分行或部分列。在联邦场景下，多个数据库节点往往只关心整体数据的一部分，例如区域节点只需要本区域订单，分析节点只需要脱敏后的统计字段。此时过滤策略就是控制数据流向的关键。
行过滤与列过滤的实现细节
行过滤是在创建发布时通过WHERE子句定义的。发布端为每个订阅维护逻辑复制槽，walsender进程读取日志并重演变更，对每一行执行发布表上的过滤条件。只有条件为真的行才会进入复制协议。INSERT和DELETE的过滤比较直观：插入的新行不满足条件就不发送，删除的旧行不满足条件也不发送。UPDATE的情况要复杂一些，PostgreSQL会分别判断旧行和新行是否满足条件。如果旧行满足而新行不满足，订阅端需要删除该行，因此会发送DELETE；如果旧行不满足而新行满足，订阅端需要新增该行，因此会发送INSERT；如果两者都满足，则发送UPDATE。这个转换机制意味着开发者在设计过滤条件时，要考虑到行在条件边界移动时可能触发操作类型变化。
列过滤则通过指定列列表实现。发布端只把列列表中的字段写入复制消息，订阅端目标表必须存在，且未被复制的列需要具备默认值或允许NULL，否则应用INSERT时会失败。列过滤同样适用于初始数据同步阶段，源端创建订阅时触发的全表快照也会按列列表裁剪。一个常见的误区是认为列过滤能减少源库日志读取量，实际上逻辑解码仍然需要读取整行，但网络传输和订阅端解析的数据量会明显下降。
下面创建一个同时包含行过滤和列过滤的发布，假设订单表orders包含tenant_id、region、order_id、amount、customer_id等字段，只向联邦节点发布华东区域订单的摘要信息：
CREATE PUBLICATION pub_east_orders FOR TABLE orders (order_id, tenant_id, region, amount) WHERE region = 'east' AND amount > 0;
这里的WHERE条件在发布端对每一行变化进行求值，列列表限制了只有四个字段进入复制流。实际执行时，如果订阅端只需要华东区域的订单金额汇总，源端不需要再额外部署触发器或中间表，逻辑复制本身就能完成数据裁剪。
联邦架构中的过滤策略设计
联邦架构通常由中心数据库和多个区域或功能数据库组成。中心库保存全量数据，区域库只保留本区域相关记录。以租户隔离为例，orders表包含tenant_id和region，华东节点订阅tenant_id在100到199之间的数据，华南节点订阅200到299之间的数据。使用行过滤可以在源端为每个目标区域创建独立发布，每个发布只匹配对应条件。
这种设计让订阅端数据规模保持可控，查询性能也更好。不过如果源表本身按region或tenant_id做了分区，逻辑复制的行过滤并不一定能自动利用分区裁剪。因为发布端在逻辑解码时仍然可能扫描到所有分区的变更，再逐行执行WHERE过滤。为了提升效率，可以按分区表分别创建发布，让不需要的分区完全不进入逻辑解码范围。比如华东节点只订阅east分区，华南节点只订阅south分区，这样比在整表上加WHERE条件更高效。
联邦环境中往往存在多级复制。中心库向下游区域库发布明细数据，区域库经过汇总后又向上游分析库发布聚合结果。此时要避免循环复制。PostgreSQL逻辑复制不会自动阻止循环，通常通过不同的发布与订阅命名、origin参数以及表级过滤来切断回路。过滤策略在这里再次发挥作用：分析库订阅的发布只包含汇总表，区域库订阅的发布只包含明细子集，数据不会原样回流。
配置联邦节点间的订阅时，可以指定是否在错误时禁用订阅，以及是否跳过初始快照：
CREATE SUBSCRIPTION sub_east_orders CONNECTION 'host=center-db port=5432 dbname=orders' PUBLICATION pub_east_orders WITH (disable_on_error = true, copy_data = true);
如果联邦中有大量区域节点，手工维护发布和订阅容易出错。建议把过滤策略抽到元数据表中，例如定义每个区域对应的tenant_id范围、region枚举和需要的列集合，再用脚本自动生成CREATE PUBLICATION语句。这样当新增区域节点时，流程是先在元数据表插入规则，再执行发布创建，避免人工遗漏某张表或某个条件。
过滤策略对性能与一致性的影响
过滤条件在发布端执行会增加walsender进程的CPU消耗。简单等值条件或范围条件在逻辑解码时开销很低，但子查询、自定义函数、易变函数会让每一行变更都产生额外计算。逻辑解码本身已经是大事务场景下的性能敏感点，复杂过滤表达式可能拖慢整个复制槽的消费速度。建议过滤条件保持在索引友好范围内，避免在WHERE中使用随机函数、时钟函数或访问其他表。
列过滤必须保证主键或唯一标识列被包含在列列表中。如果发布时把主键排除，订阅端在应用UPDATE或DELETE时无法定位目标行，会出现复制错误。行过滤同样可能带来主键冲突问题。例如一条记录从华东区域改为华南区域，旧行满足华东订阅条件而新行不满足，逻辑复制会向华东订阅端发送DELETE；同时如果华南订阅条件只匹配新行，会发送INSERT。若华南订阅端已经存在相同主键的记录，就会报duplicate key。这就要求过滤策略的业务含义必须与订阅端已有数据不发生重叠，或者在建表时使用全局唯一主键，避免跨过滤条件移动时冲突。
监控过滤复制的健康状态需要关注几个系统视图。pg_stat_subscription可以查看订阅进程的接收和应用延迟，pg_replication_slots显示复制槽的待消费WAL量，pg_stat_replication显示walsender进程的当前状态。当出现过滤导致的操作类型转换时，错误日志会明确标明表名和主键值。定期检查这些视图能帮助发现过滤条件设计不合理带来的复制延迟或错误堆积。
SELECT subname, received_lsn, latest_end_lsn, latest_end_time FROM pg_stat_subscription;
过滤复制的最终目标是让每个联邦节点只收到自己需要的增量数据，但前提是发布端条件足够简单、主键字段完整、跨边界行为经过验证。合理设计后，行过滤和列过滤能大幅减少联邦网络流量与订阅端写入压力，也能让不同节点之间的数据职责更加清晰。
PostgreSQL逻辑复制过滤策略数据联邦修改时间：2026-09-28 00:53:55