内嵌数组无限增长是MongoDB嵌入式建模中最危险隐患；它不报错但会导致性能下降、文档迁移、突破16MB限制及索引失效，根源在于将无界数据（如日志、轨迹点）错误嵌入有尺寸上限的文档中。
内嵌数组无限增长是 MongoDB 嵌入式建模中最危险的隐患之一——它不报错，但会悄悄拖垮性能、触发文档迁移、突破 16MB 限制，甚至让索引失效。
为什么数组增长会失控？常见错误现象
典型表现包括：单个文档体积从几 KB 暴涨到 8MB+、update 操作变慢且频繁失败、find 返回结果不稳定（有时漏掉新追加的数组元素）、后台日志出现 Document too large for BSON 或 cannot change the size of array element in-place。
根本原因不是 MongoDB 不支持数组，而是开发者误把「日志流」「消息队列」「变更历史」这类天然无界的数据，硬塞进一个有严格尺寸上限的文档里。
- 用
$push持续向logs数组追加操作记录，没设上限也没清理机制 - 在订单文档中内嵌所有物流轨迹点（GPS 坐标数组），每秒更新一次
- 用户行为埋点直接
$addToSet到events数组，长期运行后单文档超 5000 条
控制数组大小的三种实操方案
没有银弹，只有按场景选对策略。关键判断依据是：该数组是否需要「全部保留」「只查最新 N 条」「或仅需统计摘要」。
-
截断式写入（适合「最新 N 条」场景）：用
$push+$each+$slice组合，强制数组长度上限。例如保留最近 100 条日志：db.orders.updateOne( { _id: ObjectId("...") }, { $push: { logs: { $each: [{ ts: new Date(), msg: "paid" }], $slice: -100 } } } ) -
分片归档（适合「全部保留但低频访问」）：当数组确实要存全量（如审计日志），改用独立集合 + 引用。新建
order_logs集合，用order_id索引，读取时按需$lookup。避免主文档膨胀，也方便 TTL 索引自动过期旧数据。 -
聚合摘要（适合「只需统计值」）：如果业务只关心「共多少次操作」「最后一次时间」「错误次数占比」，就别存原始数组。改用原子更新字段：
total_events、last_event_at、error_count，每次写入只更新这几个字段。
arrayFilters 和聚合管道能救急，但不能替代设计
有人试图用 arrayFilters 在更新时做条件剔除，或用聚合管道 $set + $cond 动态裁剪数组——语法上可行，但代价极高：每次更新都要遍历整个数组，CPU 和锁竞争陡增，且无法规避文档尺寸风险。
更现实的做法是，在应用层拦截写入逻辑：
- 写入前检查
logs.length > 1000，超限则触发归档流程 - 用 MongoDB 的
change stream监听特定集合的update事件，发现数组字段被大量$push时告警 - 在 schema 层（如 Mongoose 或 GORM）定义预钩子，对目标字段做长度校验并拒绝非法写入
真正难的不是写一行 $slice，而是在建模初期就识别出哪些数组「看起来该嵌入，其实不该」——比如聊天消息列表，表面看是订单的子数据，实际访问模式是分页拉取、按时间倒序、高频追加，这种就必须拆出去。
