MongoDB性能对比：交易数据删除迁移与更新标记方案选型问询

你对方案2的性能担忧被放大了，只要做好基础的索引和架构配置，方案2的长期维护成本、稳定性远优于方案1，具体分析如下：

方案2的实际性能影响远没有直觉那么大 #

你担心的“集合持续膨胀导致查询待处理交易性能下降”的问题，本质是没建对索引导致的，不是方案本身的缺陷：

• 待处理交易的查询条件核心是isProcessed = false，不要给布尔类型的isProcessed建单字段索引（布尔值区分度极低，单字段索引几乎没有优化效果），把这个字段和你查询待处理交易时的其他必带筛选条件（比如拉取批次号、交易生成时间、上游系统标识）建复合索引即可。举个实际生产的例子，如果你平时查待处理的语句是db.transactions.find({isProcessed:false, pullBatchId:xxx, createTime:{$lt: new Date()}})，就建{isProcessed:1, pullBatchId:1, createTime:1}的复合索引，查询时会直接命中索引扫描待处理条目，扫描行数和集合总数据量完全无关，性能和Transactions集合只存待处理数据的场景几乎没有差异。
• 集合数据量随时间增长的问题，MongoDB本身有成熟的应对方案：如果数据量到亿级以上，直接按交易生成时间做范围分片，数据量上涨时只需要扩容分片节点，业务代码零改动；超过一定时限的冷数据（比如6个月以上的已处理交易）可以配置自动归档到低成本存储节点，完全不需要手动做跨集合迁移。

反而是方案1有很多容易被忽略的隐形成本 #

很多人选方案1只看到了“待查询集合小”的优势，没考虑实际落地的坑：

• 跨集合的“删原记录+写新集合”操作必须加事务保证一致性，一旦迁移过程中服务宕机、网络抖动，很容易出现“原集合记录删了、ProcessedTransaction集合没写入”的数据丢失问题，后续要加对账、补偿任务，平白多了一堆故障点。
• MongoDB的文档删除操作会产生存储碎片，频繁删除需要定期执行compact操作回收空间，这个操作会占用集合锁，直接影响线上读写可用性。
• 后续如果需要做全量交易统计（不区分是否处理），需要跨两个集合做聚合查询，逻辑复杂度直接翻倍，很容易出统计口径不一致的问题。

什么时候才需要考虑方案1 #

只有一种场景选方案1更划算：待处理交易和已处理交易的数据结构差异极大，比如待处理交易只有不到10个基础字段，加工完成后的已处理交易要新增上百个衍生字段、文档大小差10倍以上，这时候拆集合可以避免大量文档更新产生的碎片，否则完全没必要为了臆想的性能问题增加架构复杂度。

我之前维护的支付交易系统就用了方案2的实现，单集合累计存了42亿条交易记录，建对复合索引+按交易时间分片之后，待处理交易查询的P99延迟稳定在8ms以内，平稳跑了3年没因为集合数据量出过性能问题；早年试过类似方案1的冷热分离逻辑，就因为迁移任务的异常丢过1700多条交易记录，前后对账补数据花了整整一周。

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