mongodb数组频繁$push/$pull会触发文档迁移和索引重写，导致i/o激增与内存碎片；应避免将写热点与存储膨胀集中于单文档，优先用引用替代嵌入。
数组字段频繁 $push / $pull 触发文档重写与内存碎片
MongoDB 的文档在磁盘上是连续存储的 BSON 块，一旦数组元素增删导致文档大小超过原分配空间，WiredTiger 就必须执行「文档迁移」：把整个文档挪到新位置，并更新所有索引项指向新地址。这不是简单修改，而是全量重写 + 多次索引更新。尤其当数组嵌套深、元素体积大（如含 base64 图片字段）时，单次 $push 可能引发数 MB 数据搬移。
- 用
db.collection.stats()查avgObjSize和paddingFactor：若后者长期 - 避免在高频更新场景（如聊天消息、订单日志）中把全部记录塞进一个文档的数组里
- 对写密集型数组，改用独立子文档集合 + 分片键设计（例如
{orderId: ObjectId, seq: 1, content: "..."}），让写操作分散到不同物理页
索引失效与查询扫描放大效应
数组字段参与查询（如 find({tags: "mongodb"})）会触发「数组展开」——MongoDB 把每个数组元素当作独立匹配项处理。如果该字段又建了索引，每次 $push 都要向索引插入新键值对；而 $pull 则需遍历并删除多个索引条目。更关键的是：当数组过大且未加限制，explain("executionStats") 会显示 totalDocsExamined 远高于 nReturned，因为引擎要扫描整个数组才能确认是否匹配。
- 禁用对超长数组字段的直接查询，改用预聚合字段（如
hasTagMongoDB: true）或单独标签集合 - 复合索引中包含数组字段时（如
createIndex({status: 1, tags: 1})），实际索引条目数 = 文档数 × 平均数组长度，极易撑爆内存 - 用
$slice投影控制返回数组长度，但注意它不减少扫描量，只是裁剪结果
并发更新冲突集中在单文档级别
即使有索引，WiredTiger 对单个文档的写锁是排他的。当多个请求同时对同一文档的数组执行 $push（比如秒杀场景下更新库存变更日志），它们必须排队等待前一个操作完成并释放锁。此时 db.serverStatus().metrics.operation.write.conflicts 会持续上升，事务重试率飙升——这不是网络或 CPU 问题，是逻辑热点卡死。
- 用
findOneAndUpdate替代先find再update，避免应用层读-改-写窗口期 - 对计数类数组操作（如添加点赞用户 ID），优先考虑原子操作
$addToSet而非$push，减少重复写入 - 真正需要追加日志的场景，拆分为「主文档 + 时间分片子集合」，用
createdAt作为分片键，把锁竞争打散
反范式化数组带来的内存与缓存压力
把本该独立建模的数据硬塞进数组（如用户收货地址列表、商品 SKU 变体），会导致文档尺寸膨胀。WiredTiger 缓存按文档为单位加载，一个 2MB 的用户文档（含 50 条地址+100 条订单快照）会挤占大量 cache 空间，迫使其他热数据频繁进出内存。同时，该文档的任何字段更新都会让整个缓存块失效，降低缓存命中率。
- 检查
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]占比是否长期 > 95% - 对「一对多」关系，除非读取频率极高且数据量极小（如用户头像 URL 数组），否则一律用引用（
ObjectId）替代嵌入 - 用
$lookup聚合时注意内存限制：若被关联集合太大，可能触发Sort exceeded memory limit错误
