PostgreSQL的逻辑复制功能通过发布订阅模型实现数据同步。在真实业务场景中，全库同步往往不是最优选择，精准的数据过滤才是提升复制效率的关键。逻辑复制不仅支持表级别的粒度控制，还在后续版本中引入了行级过滤能力，使得数据同步更加灵活。
发布端的基础表级过滤机制
在PostgreSQL的逻辑复制架构中，发布端是数据过滤的第一道防线。最基础的过滤方式是通过控制发布对象来实现表级别的过滤。当我们在源数据库创建发布时，如果不指定具体的表，默认情况下它不会发布任何表。开发者必须显式地将需要同步的表加入到发布列表中。这种方式从源头切断了非目标表的数据传输，避免了不必要的WAL日志解析开销。
使用CREATE PUBLICATION语句时，我们可以精确指定表名，甚至可以指定只发布表中的特定操作，比如只发布插入和更新操作，而不发布删除操作。这种细粒度的控制通过WITH子句的参数来实现。例如，publish = 'insert, update'。这种机制非常适合单向数据同步场景，比如将生产库的交易数据同步到分析库，分析库不需要将删除操作同步回去，从而保证了分析数据的持续留存。
-- 创建一个仅发布插入和更新操作的发布 CREATE PUBLICATION my_pub FOR TABLE users, orders WITH (publish = 'insert, update');
表级过滤虽然简单有效，但它存在一个明显的局限性：它只能以表为单位进行全量或全量特定操作的过滤，无法针对表中的某些特定行进行过滤。如果一张表包含大量不需要同步的历史数据，表级过滤就显得无能为力，依然会将整表的所有变更发送给订阅端，造成网络和存储资源的浪费。
行级过滤规则的引入与应用
为了解决表内数据部分同步的痛点，PostgreSQL在15版本中引入了行级过滤功能。这项特性允许开发者在创建或修改发布时，为表附加WHERE条件。只有满足该条件的行发生变更时，对应的WAL日志才会被逻辑解码并发送给订阅端。这极大地提升了逻辑复制的灵活性，使得跨业务单元的精细化数据同步成为可能。
行级过滤的语法非常直观，类似于普通的SQL查询。需要注意的是，过滤条件中使用的表达式必须是基于表的列的不可变表达式，不能包含易变函数或子查询。此外，如果表结构发生变更，比如删除了过滤条件中依赖的列，逻辑复制可能会中断并报错。因此，在使用行级过滤时，必须对表结构变更流程进行严格管控，确保过滤条件的依赖项不被破坏。
-- 创建带有行级过滤的发布 CREATE PUBLICATION active_users_pub FOR TABLE users WHERE (status = 'active');
行级过滤在多租户架构中表现尤为出色。假设我们有一张订单表，包含tenant_id字段，我们可以为不同的租户创建不同的发布，每个发布只包含对应tenant_id的数据。这样，每个租户的订阅端只能接收到自己的订单变更，既保证了数据隔离，又减少了网络传输压力。不过，行级过滤也会增加发布端的CPU计算开销，因为逻辑解码器需要评估每一行变更是否满足条件，所以在高并发写入场景下需要评估性能影响。
订阅端配置与同步过程中的避坑策略
虽然过滤规则主要定义在发布端，但订阅端的配置同样至关重要。当创建订阅时，如果发布端包含了行级过滤规则，订阅端在初始数据同步阶段也会应用这些规则。这意味着COPY操作在传输初始数据时，同样会过滤掉不满足WHERE条件的数据。然而，如果订阅端的表结构与发布端不一致，或者订阅端表上存在触发器，可能会导致初始同步失败或数据不符合预期。
一个常见的陷阱是过滤条件的变更时机。如果在逻辑复制运行过程中，直接通过ALTER PUBLICATION修改了行级过滤条件，已经复制到订阅端的历史数据不会自动删除或回滚。新的过滤规则只对修改之后的增量数据生效。如果需要保持数据一致性，通常需要停止订阅，清理订阅端的历史数据，重新建立订阅以触发初始数据同步。
-- 订阅端创建订阅并接收过滤后的数据 CREATE SUBSCRIPTION my_sub CONNECTION 'host=127.0.0.1 port=5432 user=repl_user dbname=source_db' PUBLICATION active_users_pub;
此外，开发者还需要注意过滤规则与复制标识的配合。逻辑复制默认使用主键来标识行，如果一张表没有主键，且我们对其设置了行级过滤，在执行更新或删除操作时，逻辑解码器可能无法准确定位到具体的行，导致复制失败或行为异常。因此，对于参与逻辑复制且带有过滤规则的表，强烈建议设置复制标识，通常是将主键作为复制标识，以确保数据同步的准确性和稳定性。
PostgreSQL逻辑复制数据过滤修改时间：2026-08-28 01:25:05