Debezium 1.7对接Postgres 13增量快照性能远低于常规快照咨询

你观测到的性能差异核心属于1.7版本Debezium增量快照的已知预期现象，但20倍的性能差超出了常规区间，和你的测试场景配置也有关系，具体说明如下：

性能差异的固有原因 #

• 常规全量快照的逻辑是直接批量读取PostgreSQL表数据，无需和WAL流处理做协同校验，无额外流程开销，因此处理速度更快。
• 增量快照基于「分块读取+WAL水印对齐」逻辑实现：每读取一个chunk的数据，都需要先向WAL流插入信号标记，等WAL消费到对应标记位置后，对比校验chunk数据是否与WAL变更冲突，再输出事件。这套协同逻辑本身就有固定开销，1.7作为增量快照刚发布的早期版本，优化不足，常规场景下性能就会比常规快照慢3~10倍。

你当前测试场景下性能进一步下降的原因 #

你调整incremental.snapshot.chunk.size参数无收益，核心和你使用UUID作为主键有关：

• 增量快照的chunk分页依赖主键排序做范围查询，UUID属于无序主键，每次查询chunk都会产生大量随机IO，chunk调大后单轮查询的扫描成本会大幅上升，抵消了减少查询次数带来的收益，因此参数调整无明显效果。
• 1.7版本Debezium的PG连接器存在已知缺陷：对非有序主键的chunk查询未添加优化提示，很容易触发PostgreSQL走全表扫描而非索引扫描，进一步拉低查询效率。

优化建议 #

• 优先升级到Debezium 1.9及以上版本，该版本针对UUID主键的增量快照做了专门优化，同时精简了WAL协同的流程开销，性能相比1.7版本可提升2~3倍。
• 若暂时无法升级，且你使用的是有序UUID（如UUIDv1），可调整incremental.snapshot.primary.key.segments参数拆分主键段，优化范围查询的扫描效率。
• 排查PostgreSQL的慢查询日志以及Debezium日志，确认是否存在水印等待超时、chunk查询走全表扫描的问题，针对性调整PostgreSQL的执行计划参数。

内容的提问来源于stack exchange，提问作者sha