逻辑复制是PostgreSQL 10之后官方提供的数据同步方案，发布端通过逻辑解码输出wal日志，订阅端由apply worker读取消息并回放成SQL执行。整个链路上，发布端的解码固然消耗资源，但更多时候瓶颈出现在订阅端：apply worker单线程回放事务，一旦表上索引过多、约束检查开销大或者参数配置不当，写入速度会明显落后于发布端，复制延迟越积越大。这篇文章围绕订阅端写入性能展开，从执行流程、参数配置、表结构设计几个层面分析优化思路。
一、理解订阅端的写入流程与瓶颈成因
订阅端的核心进程是logical replication worker，每个订阅默认分配一个apply worker。这个进程从发布端接收逻辑复制消息，按照事务为单位回放到本地表。默认情况下，一个大事务必须完整接收后才能开始应用，这意味着发布端一个耗时很久的大事务，会在订阅端形成明显的应用延迟——数据已经全部传输过来，但必须等事务结束后才能批量写入。
订阅端写入本质上执行的是类似INSERT、UPDATE、DELETE的操作，因此所有影响普通写入性能的因素在这里同样生效。区别在于，apply worker是单线程顺序回放的（同库内事务必须保持顺序），所以订阅端无法通过简单增加并发来提升单表写入速度，除非数据被拆分到多个发布或者使用订阅端的并行应用能力。
常见的性能瓶颈包括：目标表上存在大量二级索引，每次写入都要维护所有索引；外键约束、触发器在apply时逐行触发检查；表上存在唯一索引冲突时的重复检查开销；以及max_replication_slots、max_logical_replication_workers等参数过小导致worker无法正常启动。定位瓶颈时，可以先在订阅端观察pg_stat_subscription视图，确认receive_lsn与latest_end_lsn的差距，再配合pg_stat_activity查看apply worker当前的等待事件。
二、订阅端的关键参数调优
第一个要调整的参数是max_parallel_apply_workers_per_subscription，它控制订阅端单个apply进程可以启用的并行worker数量，仅在streaming设置为parallel时生效。并行应用要求订阅端为每个worker分配独立的并行事务槽，因此max_logical_replication_workers和max_worker_processes都要留够余量，一个常见的配置是worker总数设置为按订阅数加并行数计算后再留百分之二十的冗余。
streaming参数决定了大事务的处理方式，可选值有off、on和parallel。off是传统模式，事务必须完整接收后才能应用；on模式允许事务在接收过程中就开始流式应用，避免大事务整体等待；parallel则进一步把同一个大事务的变更分发给并行worker回放。对于发布端经常出现大事务的场景（比如批量UPDATE百万行），开启streaming能显著降低延迟，但要注意并行模式下依赖冲突处理的复杂度上升，遇到约束冲突时回滚行为需要仔细验证。
-- 查看当前订阅定义 SELECT subname, subslotname, subpublications FROM pg_subscription; -- 修改订阅参数：开启流式并行应用 ALTER SUBSCRIPTION my_sub SET (streaming = parallel, max_parallel_apply_workers_per_subscription = 4); -- 确认worker相关上限参数（需重启生效） SHOW max_logical_replication_workers; SHOW max_worker_processes;
除了复制专用参数，订阅端的work_mem也值得关注。apply过程中如果要维护排序、哈希或者执行子查询触发器，内存不足会落盘影响速度。另外logical_decoding_work_mem在发布端控制解码缓冲，如果这个值偏小，大事务会把变更spill到磁盘，间接拖慢订阅端接收速度。建议根据事务规模适当调大，一般从64MB起步观察。
三、表结构与约束层面的优化
订阅端表上的索引数量直接影响apply速度。逻辑复制的UPDATE和DELETE依赖副本标识（replica identity）来定位目标行，默认使用主键。如果表没有主键，必须设置FULL模式，此时订阅端要靠全表扫描匹配行，性能会急剧恶化。因此规范做法是确保每张复制表都有主键，或者选择一个非空且唯一的索引作为副本标识：
-- 为没有主键的表设置基于唯一索引的副本标识 ALTER TABLE orders REPLICA IDENTITY USING INDEX orders_order_no_idx; -- 查看表的副本标识模式 SELECT relname, relreplident FROM pg_class WHERE relname = 'orders';
约束方面，订阅端的外键约束会在每行写入时触发父表检查，批量回放时这个开销被放大数倍。如果业务能保证数据一致性由发布端保证，可以在订阅端临时移除外键，或者把外键改为NOT VALID状态先跳过校验。同理，触发器可以用ALTER TABLE ... DISABLE TRIGGER USER关闭用户触发器，但系统触发器仍需保留。要注意这些做法牺牲了一部分本地数据保护，需要权衡业务风险。
索引维护的另一个思路是分阶段处理：初始化数据同步阶段可以先删掉非必要索引，等初始快照应用完毕后再重建。重建索引用maintenance_work_mem加大内存并开启并行构建，能明显缩短维护窗口。不过这种方案只适合初始化场景，持续复制阶段频繁删建索引反而会造成中断期数据堆积，不建议常态化操作。
四、监控与延迟排查的实践方法
判断订阅端是否写入性能不足，核心指标是复制延迟。可以对比发布端pg_replication_slots中的confirmed_flush_lsn与当前wal LSN，得到发布端视角的延迟；订阅端则看pg_stat_subscription中的last_msg_send_time与last_msg_receipt_time差值，以及latest_end_time与当前时间的差距。延迟稳定在一个小范围属于正常抖动，持续增长才是性能问题的信号。
-- 发布端查看各订阅槽的确认位点
SELECT slot_name, active, confirmed_flush_lsn, pg_current_wal_lsn() AS current_lsn,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag_size
FROM pg_replication_slots;
-- 订阅端查看apply worker状态
SELECT subname, pid, received_lsn, latest_end_lsn, latest_end_time
FROM pg_stat_subscription;
排查时建议按顺序确认几件事：worker是否全部启动，有没有因为worker数量上限被阻塞；apply worker的等待事件是什么，如果是Lock说明存在锁冲突，可能是本地的长事务或备份任务持锁；如果是ClientRead则说明订阅端处理不过来，瓶颈在本地写入。结合pg_stat_user_tables的seq_scan和idx_tup_hot_upd字段还能判断副本标识是否走的全表匹配。
总体来看，订阅端写入性能优化是一个组合动作：参数上开启streaming与并行应用并保证worker配额充足，结构上确保主键副本标识、精简索引与约束，运维上建立延迟监控和等待事件分析的习惯。多数复制延迟问题都能在这三个层面找到答案，遇到极端大事务场景时再考虑业务侧拆分事务，从源头减少单事务规模，延迟就能稳定控制在可接受的范围内。
PostgreSQL逻辑复制订阅端性能修改时间：2026-09-13 10:10:34