适合，但仅当满足以下条件：timefield明确且不可变、有唯一metafield标识序列、写入追加式、查询常按metafield+时间范围组合、无需跨metafield复杂关联。
按时间拆分集合不是必须的，但对归档场景非常实用——前提是你的查询模式以时间范围为主、写入集中、读取稀疏，且没有强事务或跨时间窗口关联需求。
归档数据是否适合用时间序列集合？
适合，但仅当满足以下条件：
• timeField 明确（如 created_at 或 event_time）且不可变
• 每条文档有唯一标识该时间序列的 metaField（如 device_id、sensor_id、user_id）
• 数据写入是追加式、极少更新或删除（归档场景天然契合）
• 查询常按单个 metaField + 时间范围组合进行（例如“查某设备最近7天数据”）
• 不需要跨多个 metaField 做 JOIN 或复杂关联聚合
如果只是单纯存日志、埋点、IoT采样，且不打算频繁跨设备查统计，timeSeries 集合比手动按月建集合更省心：MongoDB 自动分桶、压缩、索引优化，_id 也不强制要求。
手动按月/按天拆集合的风险点
容易踩的坑比想象中多：
• 集合名动态生成时，date.getMonth() + 1 忘加 padStart(2, '0') → 出现 logs_2026_7 和 logs_2026_07 两个不同集合
• 查询跨月数据时，应用层要自己 map 多个集合再 concat 或 merge，出错概率高
• mongosh 或监控工具无法对“一组集合”统一做 db.collection.stats()，运维成本陡增
• 如果后期想迁移到分片集群，每个时间子集合需单独配置分片键，无法继承父集合策略
• 删除旧数据时，dropCollection 比 deleteMany 更快，但会丢失 collection-level 的 TTL 索引和审计元信息
什么时候该用分片而不是拆集合？
当单集合文档数稳定超过 5000 万，且查询延迟开始波动（尤其带 $gte/$lt 时间范围时），优先考虑分片而非拆集合：
• 分片键选 { timestamp: 1, _id: 1 } 或 { meta_id: 1, timestamp: 1 }，兼顾时间范围查询与写入均匀性
• 单集合 + 分片能复用所有 MongoDB 原生能力（事务、change stream、$lookup 跨集合聚合）
• sh.splitAt() 和 sh.moveChunk() 可在线调整，比手动迁移历史数据灵活得多
• MongoDB 7.0+ 对分片集合的碎片整理已基本自动化，不用定期 defragmentCollection
真正需要手动拆集合的，往往是冷数据归档到独立副本集、或法规要求物理隔离（比如按年存到不同云区域），而不是性能瓶颈驱动。
归档设计最易被忽略的一点：**时间字段的时区一致性**。ISODate("2026-07-21T00:00:00Z") 和 ISODate("2026-07-21T00:00:00+0800") 在 $gte/$lt 查询中行为完全不同，且无法靠应用层格式化掩盖——它直接影响分桶边界、TTL 过期、以及跨集合查询结果的完整性。
