单独建集合更稳妥，尤其当历史记录需查询、删除、审计或长期保留时；嵌入式历史存在索引低效、文档膨胀、全表扫描、无法TTL过期及并发写冲突等问题，生产环境应避免混合使用。
单独建集合更稳妥，尤其当历史记录要查、删、审计或保留多年时。
历史记录频繁查询或反向追溯时，嵌入主文档会拖慢性能
嵌入式历史（比如 history 字段存数组）看似省事，但一旦要查“谁在什么时间改过这个字段”，就得用 $unwind + $match，内存开销大、无法高效索引。MongoDB 对数组内嵌文档的索引能力有限，history.timestamp 单独建索引效果差，而 history 数组本身又容易触发文档膨胀——每次更新都 push 新项，BSON 大小逼近 16MB 上限。
- 反向查（比如“所有修改过 user_id: 'U123' 的操作”）必须全表扫描嵌入数组，没法走索引
- 导出某段时间的历史记录时，得先读主文档再过滤数组，网络和 CPU 双重浪费
- 备份或归档旧历史时，没法只删
history部分，只能整文档迁移或重建
独立集合必须带业务主键和时间戳复合索引
建一个 audit_log 或 user_history 集合，字段至少包含：target_id（被操作文档的业务 ID，不是 ObjectId）、action（"update"/"delete"）、timestamp、operator、diff（变更字段 JSON）。关键点是：target_id 和 timestamp 必须建复合索引 { target_id: 1, timestamp: -1 }，否则按用户查最近 10 条历史会扫全集合。
-
target_id用字符串业务 ID（如"user_789"），别用ObjectId—— 后续跨系统对账、ETL 导出时 ID 不一致，还得额外维护映射表 - 如果历史要支持按操作类型筛选，加
action到索引前缀，比如{ action: 1, target_id: 1, timestamp: -1 } - 避免在历史文档里存完整快照，只存
diff或关键字段变更；全量快照既占空间又难比对
嵌入式只适合极简场景：单次记录、永不查询、生命周期短
比如一个订单状态流转，只记 status_history: [{ status: "created", at: ISODate("...") }, ...]，且从不按时间范围查、不审计、不导出，那可以嵌入。但只要需求变成“查上周所有已取消订单”，嵌入结构立刻失效。
- 嵌入后无法对历史做 TTL 自动过期（
expireAfterSeconds只支持根级date字段） - 写入并发高时，多个 update 同时 push 到同一个
history数组，可能因文档重写引发写冲突或丢失条目 - 应用层做 diff 逻辑得反复解析整个主文档，而不是只读轻量历史集合
真正麻烦的不是选哪种方式，而是混合使用——比如主文档里嵌最近 3 条，再往独立集合存全部。这会让查询路径分裂、索引策略打架、运维脚本变复杂。要么全嵌入（仅限 demo 或原型），要么全分离（生产首选），中间态最容易出问题。
