$unwind会成为性能瓶颈，因其本质是文档爆炸操作：一条含n个元素的数组文档展开为n条独立文档，导致数据流体积剧增，后续$sort、$group等操作在放大后的数据集上运行，显著加剧内存与CPU压力，易引发OOM或超时。
为什么$unwind会成为性能瓶颈
$unwind 不是“展开数组”这么简单，它本质是文档爆炸操作：一条含 5 个元素的数组文档，$unwind 后变成 5 条独立文档。数据流体积瞬间翻倍，后续 $sort、$group、$match 都在放大后的数据集上运行，内存和 CPU 压力陡增。尤其当聚合管道里还有 $lookup 或复杂 $project 时，OOM 或超时几乎是必然结果。
常见错误现象：explain("executionStats") 显示 nReturned 很小但 totalDocsExamined 是前者的几十倍；executionStages.stage 出现大量 UNWIND + COLLSCAN 组合；应用层收到的响应体比预期大一个数量级。
用内嵌结构替代数组，避免$unwind触发条件
不是所有数组都该存在。如果数组项之间无独立生命周期、不单独查询、不按子项字段高频筛选（比如日志条目、传感器原始采样点、订单明细），就该考虑是否本就不该建模为数组。
- 把高频读取的“关键属性”冗余为顶层字段，例如把
user.tags中最常查的"urgent"提到is_urgent: true - 用固定长度结构体代替变长数组，比如订单状态流转用
status_history: [{ts: ..., from: ..., to: ...}]→ 改为created_at: ..., confirmed_at: ..., shipped_at: ..., delivered_at: ... - 对确实需要数组的场景，限制单文档内数组长度（如
maxItems: 10），并在应用层校验，防止后期膨胀失控
用$reduce或$filter代替$unwind做轻量级数组处理
当目标只是“从数组中找一个值”或“过滤后取第一个”，$unwind 完全多余。MongoDB 4.2+ 提供更高效原语：
- 查数组中满足条件的首个元素：
{$set: {matched_tag: {$arrayElemAt: [{$filter: {input: "$tags", cond: {$eq: ["$$this.name", "urgent"]}}}, 0]}}} - 统计匹配数量：
{$addFields: {urgent_count: {$size: {$filter: {input: "$tags", cond: {$eq: ["$$this.priority", "high"]}}}}}} - 排序后取 top N（不还原结构）：
{$set: {top3_scores: {$slice: [{$sortArray: {input: "$scores", sortBy: {value: -1}}}, 3]}}}
这些操作都在单文档内完成，不产生新文档，也不触发 WiredTiger 缓存压力。
必须用$unwind时，如何最小化副作用
有些场景绕不开，比如按数组元素分组统计、跨文档关联子项、或前端强依赖“每行一条子记录”。这时要控制爆炸范围：
- 前置
$match尽可能缩小输入文档集，别让 $unwind 处理十万条文档，只让它处理命中后的几百条 - 用
preserveNullAndEmptyArrays: true，否则空数组文档直接消失，业务逻辑可能漏数据 - 避免连续多个 $unwind（如
$unwind: "$a"→$unwind: "$a.b"），这会让文档数呈乘法级增长；改用$map+$reduce在内存中组合 - 聚合末尾务必
$group回收，且_id必须用原始$_id，否则丢失父文档上下文——这是线上事故高发点
真正难的不是写对语法，而是判断“这个需求到底需不需要 $unwind”。多数时候，问题出在模型设计层，而不是聚合写法层。
