MongoDB中无界数组会导致性能下降和写入失败，因其违背文档模型引发迁移、索引膨胀与内存压力；应避免用数组存日志等增长数据，改用独立集合+复合索引，或用$push+$each+$slice原子截断。
为什么数组无限增长会让MongoDB变慢又危险
文档体积超16MB直接写入失败，但更常见的是性能滑坡：索引膨胀、内存压力、复制延迟。根本问题不在“大”，而在“无界数组”天然违背MongoDB的文档模型——它把关系型里的“一对多”硬塞进单文档，结果是每次 $push 都可能触发文档迁移、重写整条记录。
典型错误现象：Document too large for the collection、moveChunk failed、查询响应时间随天数线性上升。
- 别用数组存日志、事件流、评论列表这类天然增长的数据
- 如果必须保留历史（比如用户操作审计），用独立集合 + 复合索引（
userId,timestamp）替代嵌套数组 - 已有大文档？别用
$pop或$slice临时截断——这只是掩耳盗铃，下次写入仍会突破上限
用 $addToSet 和 $push 的边界条件判断是否真需要“去重”或“保序”
很多人默认用 $addToSet 防重复，却没意识到它底层要遍历整个数组做比较——当数组已有5万条时，一次更新就卡住几秒。而 $push 虽快，但若业务其实不需要全量保留（比如只关心最近100次登录IP），盲目追加就是给自己埋雷。
- 检查业务逻辑：是否真的需要“所有值”？还是只需最新N条？用
$push+$each+$slice组合可原子截断，例如：{ $push: { ips: { $each: ["192.168.1.1"], $slice: -100 } } } - 如果必须去重且数据量小（$addToSet 可接受；否则改用集合级唯一索引 + 应用层判重
-
$addToSet对嵌套文档无效（只比对字段名和值，不递归），误用会导致看似去重实则重复插入
替换方案：什么时候该拆成子集合，而不是硬撑嵌套结构
判断标准很直白：只要数组元素本身有独立ID、需要单独查询/更新/聚合，或者单个元素超过1KB，就必须拆。MongoDB不是JSON存储桶，它是为“合理粒度文档”设计的。
- 反例：把用户所有订单详情都塞进
user.orders数组里 - 正例：建
orders集合，用userId字段关联，加索引{ userId: 1, createdAt: -1 } - 迁移时别用应用层逐条读写——用
mongosh的db.users.aggregate()+$unwind直接管道写入新集合，避免网络往返开销 - 注意引用一致性：删除用户时，别只删主文档，得同步清理
orders集合中对应记录（用db.orders.deleteMany({ userId: "xxx" })）
监控和兜底：怎么提前发现“悄悄长胖”的文档
靠人工查不到问题，等报错就晚了。关键是建立体积基线+自动告警。
- 定期跑聚合查最大文档尺寸：
db.collection.aggregate([ { $project: { size: { $bsonSize: "$$ROOT" } } }, { $sort: { size: -1 } }, { $limit: 1 } ]) - 在应用写入前加校验：用
Object.bsonSize(doc)（Node.js驱动）或len(bson.encode(doc))（Python）预估大小，超12MB就拒绝并打日志 - 别依赖
db.collection.stats().avgObjSize——它掩盖了长尾，真正危险的是那个20MB的 outlier 文档，不是平均值
最常被忽略的一点：即使你严格控制了数组长度，如果数组里存的是Base64图片或大JSON blob，照样秒破16MB。体积控制必须穿透到字段层级，不能只数元素个数。
