MongoDB 7.0副本集不支持物理拆分集合，聚合管道无法直接“拆分”集合；所谓“拆分”实为通过$out或$merge将筛选/转换后的数据写入新集合，属一次性逻辑分流，需人工配合应用切换与数据验证。
直接说结论：MongoDB 7.0 副本集本身不支持“拆分集合”，aggregate 也不能把一个集合物理切开；所谓“利用聚合管道拆分”，本质是用 $merge 或 $out 阶段将结果写入新集合，实现逻辑分流——这不是分片，也不是在线迁移，而是一次性的数据导出+重组织。
为什么不能在副本集上用聚合“拆分”集合
副本集是高可用架构，不是水平扩展架构。它没有 mongos、没有 config server、没有 chunk 拆分机制，所有读写都落在主节点（或从节点读），sh.shardCollection() 在副本集上执行会报错 not enabled for sharding。聚合管道运行在单节点上，输出再大也只在一个实例内完成，无法自动分散到多个物理集合或分片。
常见误解是看到 $split 或 $slice 就以为能“拆集合”，其实它们只作用于数组字段，和集合层级无关。
-
$merge和$out是唯一能“落地”为新集合的聚合阶段，但它们会覆盖目标集合（$out）或按条件合并（$merge），不改变原集合结构 - 试图在聚合中用
$lookup关联另一个集合再写回，容易因内存超限触发errmsg: "Sort exceeded memory limit" - 如果原集合超 100GB，聚合过程可能长时间持有读锁（WiredTiger 下为文档级锁，但大聚合仍可能阻塞写入）
真正可行的“拆分”路径：$out + 手动切换应用
适用于需要按时间、租户、业务线等维度分离历史数据的场景，比如把 logs 按月导出为 logs_202608、logs_202609。
操作必须在维护窗口执行，且需确认目标数据库有足够磁盘空间：
- 先建好目标集合索引（别等
$out完了再建，太慢）：db.logs_202608.createIndex({ts: 1, service: 1}) - 用
$out导出指定范围数据：db.logs.aggregate([{$match: {ts: {$gte: ISODate("2026-08-01"), $lt: ISODate("2026-09-01")}}}, {$out: "logs_202608"}]) - 验证新集合文档数和原范围一致：
db.logs.countDocuments({ts: {$gte: ISODate("2026-08-01"), $lt: ISODate("2026-09-01")}})vsdb.logs_202608.countDocuments({}) - 应用层修改查询逻辑，对旧数据查新集合，新数据继续写原集合（或改写入新集合）
想接近“自动拆分”？只能靠应用层轮询 + $merge
如果希望按某种规则（如每 500 万文档）持续分流，MongoDB 本身不提供定时/阈值触发机制。必须由外部脚本控制：
- 用
db.collection.stats().count查当前文档数，判断是否达到阈值 - 取最后一批文档的
_id或时间戳作为游标，用$merge写入带版本号的目标集合：{$merge: {into: "logs_v2", on: "_id", whenMatched: "keepExisting", whenNotMatched: "insert"}} - 成功后调用
db.logs.deleteMany()清理已导出部分（注意：这会产生物理删除，WiredTiger 不立即回收磁盘空间） - 务必在
rs.stepDown()后再删，避免主从同步延迟导致数据丢失
真正的难点不在聚合语法，而在于如何让应用无感切换、如何保证两次聚合间的数据不丢不重、以及 $out 期间原集合不可写——这些都不是加个管道阶段能解决的。
