MongoDB Change Streams配置FullDocument=UpdateLookup是否影响源库性能？

核心机制确认 #

你的理解完全正确：开启fullDocument: updateLookup配置后，Change Streams每捕获到一条更新类型的oplog事件，都会在对应集合上触发一次按_id的单文档查询，用于拉取变更后的完整文档，该查询由MongoDB服务端侧执行，不是驱动或连接器层面的逻辑。
该查询命中默认主键索引，本身开销极低，但在高写入场景下，大量查询累加确实会产生额外读负载，会一定程度抵消Change Streams原本仅读oplog的低开销优势。
另外MongoDB 4.4版本并未提供updateLookup的批量查询优化，每一条更新事件都会对应独立的单文档查询，没有办法通过配置减少查询总次数。

适配你的部署场景的优化方案 #

结合你使用Kafka Mongo Source连接器、MongoDB 4.4、高写入集合的背景，可按优先级选择以下方案降低对业务库的影响：

• 优先判断是否必须使用全文档返回：如果业务逻辑只需感知变更字段，可关闭updateLookup配置，直接读取事件中的updateDescription字段获取变更前后的字段值，完全没有额外查询开销，对业务库无影响。
• 强制Change Streams读从节点：在连接器的MongoDB连接串中配置readPreference=secondaryPreferred，让所有的oplog拉取、updateLookup查询都优先打到从节点执行，完全不会占用主库的业务写入资源，是目前生产环境高写入场景下的通用解决方案，只要从节点资源预留充足，每秒上万次的主键查询基本不会产生性能瓶颈。
• 调整游标批大小：在连接器配置中调高Change Streams的batchSize参数，减少游标与服务端的交互次数，虽然无法减少总查询量，但可以降低网络交互的额外开销。

额外注意事项 #

如果你的集合开启了分片，updateLookup的查询会自动路由到对应分片的节点，不会产生跨分片查询开销，本身性能损耗可控，只要做好读写分离基本不会影响上层业务。

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