更改流生产建议
如果您在开启更改流时删除或重命名一个集合或数据库，更改流游标在它们推进到oplog中的该点时将关闭。带有fullDocument : updateLookup 选项的更改流游标可能对查找文档返回 null。
更改流响应文档必须遵守16MB BSON文档限制。根据您对集合打开更改流时文档的大小，如果结果通知文档超过16MB限制，则通知可能会失败。例如，更改流配置为返回完整更新文档的更新操作，或者具有达到或略低于限制的文档的插入/替换操作。
重要
从版本6.0.9开始，您可以使用$changeStreamSplitLargeEvent 聚合阶段将事件分割成更小的片段。
副本集
对于具有仲裁者成员的副本集，如果足够的数据承载成员不可用，以至于无法进行多数提交，更改流可能会保持空闲状态。
例如，考虑一个具有两个数据承载节点和一个仲裁者的3成员副本集。如果次要节点失败，例如由于故障或升级，则无法进行多数提交。更改流保持打开，但不发送任何通知。
在这种情况下，只要应用程序接收到的最后一个操作仍在副本集的oplog中，应用程序就可以赶上所有在停机期间发生的操作。
如果预计会有显著的中断，例如升级或重大灾难，请考虑增加oplog的大小，以便操作保留的时间超过预计的中断时间。使用 rs.printReplicationInfo() 获取有关oplog状态的信息，包括oplog的大小和操作的时间范围。
分片集群
通过使用全局逻辑时钟，Change streams提供了跨分片的更改的总排序。MongoDB保证更改的顺序被保留，并且更改流通知可以安全地按接收顺序解释。例如，针对具有3个分片的分片集群打开的更改流游标返回尊重所有三个分片更改总顺序的更改通知。
为了保证更改的总排序，对于每个更改通知，mongos会检查每个分片，看该分片是否看到了更近期的更改。具有一个或多个几乎没有活动或“冷”分片的分片集群可能会对更改流的响应时间产生负面影响，因为mongos必须检查这些冷分片以确保更改的总排序。这种影响在地理分布的分片或大多数操作发生在集群中某些分片子集的工作负载中可能更为明显。为了最小化冷分片的延迟，您可以指定一个较低的periodicNoopIntervalSecs值。
如果分片集合的活动水平很高，mongos可能无法跟上所有分片之间的更改。考虑为这些类型的集合使用通知过滤器。例如，传递一个配置为仅过滤insert操作的$match管道。
索引和性能
更改流无法使用索引。MongoDB 不支持在 oplog 集合上创建索引。因此，避免打开大量 特定目标的 更改流，因为这些可能会影响服务器性能。
更改流优化
从 MongoDB 5.1 开始，更改流得到优化，提供了更高效的资源利用和一些聚合管道阶段的更快执行。