MongoDB数据版本化需应用层显式实现：添加整数schemaVersion字段，按版本分支读写，双写过渡，补全字段，分集合存档，并确保备份、CDC等全链路适配版本契约。
用 schemaVersion 字段做轻量级版本路由
最直接的方式是在每个文档里加一个 schemaVersion 字段，值为整数（如 1、2），应用层读取时根据该字段决定如何解析结构。MongoDB 本身不校验这个字段，但你的业务代码必须严格分支处理：
• 查询时不能忽略该字段，否则旧版字段缺失会引发空指针或类型错误
• 写入新文档必须显式设为最新版本号，避免混入未定义行为的“无版本”文档
• 迁移旧文档时，只改 schemaVersion 不够，得同步补全新增字段（比如 V2 要求 seoKeywords 数组，V1 文档就得初始化为空数组）
• 不建议用字符串（如 "v2.1"）当版本标识，整数比较快、排序天然有序、索引效率高
历史数据分离到 collection_name_history 集合
当模式变更涉及字段语义重定义（比如把 homePhone 和 cellPhone 合并进 contacts 数组），保留原始文档结构比强行转换更安全。这时应把旧版本文档写入独立集合：
• 新集合名按约定加 _history 后缀，例如 users → users_history
• 历史文档需保留原始 _id（存为 originalId），并增加 version、archivedAt 字段
• 当前集合只存最新版，查询性能不受影响；历史查询走专用集合，可建针对性索引（如 { originalId: 1, version: -1 }）
• 注意：不要在历史集合上建唯一索引约束，因为同一 originalId 可能有多个版本
时间戳 + 分片键对齐才能支撑快照查询性能
如果历史快照查询是高频操作（比如查“2026-04-10 当天所有变更”），仅靠 schemaVersion 或分集合还不够，必须让物理存储与查询模式一致：
• 单纯给 updatedAt 建索引只能加速单分片内的扫描，跨分片广播仍是瓶颈
• 分片键必须含时间维度，例如 { tsPrefix: 1, _id: "hashed" }，其中 tsPrefix 是写入时计算的年月字符串（"2026-04"）
• 查询时必须带上 tsPrefix 条件，MongoDB 才能路由到 1 个分片，避免全集群扫描
• 切忌用 _id 或 UUID 做唯一分片键——它会让时间范围查询打散到全部分片，性能随分片数线性恶化
备份与 CDC 必须区分版本上下文
版本控制不是只改文档结构，整个数据链路都要适配：
• mongodump 备份当前集合时，默认不含历史集合，要显式指定多个集合名，否则恢复后丢失版本追溯能力
• Flink CDC 的 initial 模式会全量读当前集合，但不会自动读 _history 集合；若需归档历史变更，得单独配置一个 job 订阅历史集合
• oplog 只记录变更事件，不包含文档原始版本信息；所以 CDC 捕获的 update 事件，其 before 状态可能来自 V1 结构，after 来自 V2，下游必须按 schemaVersion 分流处理
• Atlas 自动备份不感知业务版本逻辑，它只按物理集合备份，历史集合得单独确认是否纳入备份策略
实际最难的不是建字段或分集合，而是让所有数据出口（备份、CDC、导出脚本、ETL 任务）都意识到“版本”不是元数据标签，而是影响数据形状和语义的根本契约。漏掉任意一环，历史快照就变成不可解释的二进制碎片。
