聚合管道

• $match 前置以利用索引、减少数据量
• $project 提前裁剪字段
• $group/$sort 阻塞，$limit 配合 $sort 做 top-k

聚合管道各阶段的执行顺序影响性能，优化策略是：把 $match 放到最前，因为它能用索引过滤并大幅减少后续阶段的数据量；$project 尽早执行以裁剪字段，减少内存与传输；$group 与 $sort 是阻塞型阶段，需收集全部数据后进行，占用内存；$limit 紧跟 $sort 时可做 top-k 优化（只保留前 N 条，避免全量排序）；$limit 单独放在前面可减少后续处理的数据量。优化器会自动做部分重排（如把 $match 提前），但开发者主动按"过滤→裁剪→分组→排序→限制"的顺序写，能获得更优的执行计划。应避免把 $match 放在 $group 之后（过滤效果差）。

聚合优化的核心是"数据越早越小越好"。$match 前置利用索引、$project 提前裁剪、$sort+$limit 做 top-k，都是减少数据量与内存的要点。理解各阶段"过滤/裁剪/阻塞/限制"的特性，才能写出高效管道。优化器重排是辅助，主动顺序才是关键。

• 管道由有序阶段组成，每阶段处理上一阶段输出
• 阶段类型：过滤、投影、分组、排序、关联、限制等
• 顺序影响正确性与性能

聚合管道是 MongoDB 中一组有序的文档处理阶段，每个阶段接收上一阶段的全部文档，处理后输出给下一阶段。常见阶段包括：$match（过滤）、$project（投影/裁剪）、$group（分组聚合）、$sort（排序）、$limit（限制条数）、$skip（跳过）、$unwind（展开数组）、$lookup（跨集合关联）、$facet（多面聚合）、$merge（写回）等。阶段按声明的顺序执行，但优化器会对部分阶段重排以提升性能（如把 $match 移到前面）。阶段顺序影响结果正确性与性能：过滤应前置、阻塞阶段应尽量靠后、大结果集应加 $limit。理解各阶段职责与顺序，是设计聚合的关键。

聚合管道的本质是"阶段化流水线"。理解"每个阶段处理上一阶段输出、顺序影响正确性与性能、优化器可重排"，是回答的核心。分类记忆阶段（过滤/投影/分组/排序/关联/限制）有助于设计。优化器重排不改变最终结果，但能提升性能。

• $facet 在单个阶段内执行多个子管道
• 各子管道独立处理同一输入文档
• 返回多面结果，适合仪表盘多维度统计

$facet 是聚合管道中用于多面聚合的阶段，允许在单个管道中并发（逻辑上）执行多个子管道（sub-pipelines），每个子管道对同一输入文档集独立处理，输出各自的聚合结果。它适合一次查询生成多个维度/面的统计结果，如仪表盘上的多个计数、分组、排序结果。$facet 的每个子管道可以包含完整的聚合阶段（$match、$group、$sort 等）。输出是一个文档，每个子管道对应一个字段（数组）。$facet 的注意点：每个子管道都需扫描/处理输入，输入越大开销越大；且 $facet 是阻塞阶段，占用内存。适合需要多维度统计且输入可控的场景。

$facet 的价值是"一次聚合输出多面结果"。理解"多个子管道对同一输入独立处理"是关键。$facet 是阻塞阶段，内存有限，需注意输入规模。它常用于仪表盘多维度统计，减少多次查询。与 $bucket 等组合可做多面直方图。

• 各累加器在 $group/$project 中的语义
• $push/$addToSet 会累积数组，内存占用大
• 内存边界与 100MB 限制

聚合管道的累加器用于 $group 分组内聚合。$sum 求和、$avg 求平均、$first/$last 取分组内首/尾文档字段、$push 把值追加为数组、$addToSet 去重后并入数组、$top 取排序后前 N 个。语义差异：$sum/$avg 数值聚合，$first/$last 依赖分组输入顺序，$push/$addToSet 累积数组（可无限增长），$top 需排序。内存边界：$push/$addToSet 累积的数组大小随分组内文档数增长，会占用大量内存；$group 阶段整体受 100MB 内存限制（默认），超出需 allowDiskUse 落盘。大分组用 $push/$addToSet 易撑爆内存，需控制分组规模或改用其他累加。

累加器的选择要匹配"聚合类型"与"内存边界"。$sum/$avg 稳定，$push/$addToSet 累积数组有内存风险，$top 需排序。理解 100MB 内存限制与 allowDiskUse，是评估聚合内存的关键。大数组累积应谨慎，必要时落盘。

• pipeline 语法允许对关联集合做多个阶段
• let 定义本地变量，pipeline 中用 $$var 引用
• 实现条件关联、过滤、非等值关联

$lookup 的 pipeline 语法（let + pipeline）允许在关联时对"from"集合执行子管道，实现更复杂的关联逻辑。let 定义本地变量（如当前文档的字段），pipeline 内用 $$var 引用这些变量，从而可以按当前文档字段做条件过滤、非等值关联、多条件关联等。相比普通等价关联（localField/foreignField），pipeline 语法更灵活，但性能差异显著：普通等价关联可直接用 from 集合上的 foreignField 等值索引高效匹配；pipeline 语法通常把当前文档的每个值作为参数传入子管道，子管道内若匹配条件与索引不匹配（如非等值、表达式计算），则可能无法高效利用索引，导致每个本地文档都要在外部集合扫描，性能下降。因此，能用普通等价关联时优先用；pipeline 语法用于需要复杂过滤/非等值关联的场景，并尽量让子管道匹配条件可索引。

$lookup pipeline 语法与普通关联的核心差异是"灵活性 vs 索引利用"。普通等价关联索引友好，pipeline 灵活但需注意索引匹配。理解"let 传参 + $$var 引用 + 子管道"与"索引是否可用"，是回答的关键。复杂关联需权衡性能。

• 阻塞阶段：$sort、$group、$facet、$merge 等需收集全部数据
• 流式阶段：$match、$project、$limit、$unwind 等可边读边输出
• 阻塞阶段占用内存、增加端到端延迟

聚合阶段分为阻塞型与流式型。阻塞型阶段（$sort、$group、$facet、$bucket 等）需要接收全部输入文档后才能产生输出，因此必须在内存中暂存全部数据，占用内存大，且只有全部输入到达后才输出，增加端到端延迟；流式阶段（$match、$project、$limit、$unwind、$addFields 等）可对每个输入文档立即处理并输出，不阻塞、内存占用小、延迟低。评估阻塞阶段的影响：阻塞阶段使管道无法流式输出，内存占用受 100MB 限制（超限需 allowDiskUse 落盘），端到端延迟随输入规模上升。设计管道时应尽量把阻塞阶段后置、减少输入到阻塞阶段的数据量，或把阻塞阶段与流式阶段合理组合。

阻塞 vs 流式是聚合性能的关键。阻塞阶段（sort/group/facet）占内存、延迟高；流式阶段低延迟。理解"阻塞阶段需全量输入 + 内存限制 + 延迟增加"，是评估管道性能的基础。优化方向是减少阻塞阶段输入并合理落盘。

• $lookup 用于跨集合关联，替代反规范化查询
• 性能依赖外部集合索引
• 大批量关联性能差

$lookup 用于在聚合管道中把"from"集合的相关文档关联到当前文档，应用场景包括：需要关联多个集合的数据（如订单关联用户、商品）、避免应用层多次查询、做只读关联查询。性能方面：$lookup 的性能强依赖 from 集合的 foreignField 索引，若已建索引则可用索引匹配，效率较高；若无索引则退化为全表扫描，每个本地文档都要扫描外部集合，性能极差。$lookup 是"每本地文档一次外部匹配"，本地文档量大时开销大。因此使用 $lookup 前应确保 foreignField 有索引，并评估关联规模；对高频、大表关联，可考虑反规范化（冗余字段）替代 $lookup 以提升读性能。

$lookup 的性能核心是"索引 + 关联规模"。理解"索引决定匹配效率、规模决定总开销"，是使用 $lookup 的关键。$lookup 是只读关联，不写外部集合。高频场景可反规范化替代。合理使用 $lookup 需要索引与规模评估。

• $lookup 无索引时全表扫描
• $unwind 展开数组导致文档爆炸
• 高频关联场景应反规范化

$lookup 与 $unwind 是常用的关联与展开阶段，但也有性能陷阱。$lookup 陷阱：若 from 集合的 foreignField 没有索引，会退化为全表扫描，每个本地文档都扫描外部集合，性能灾难性；$unwind 陷阱：$unwind 展开数组会把一个文档拆成多个（数组有 N 个元素就成 N 个文档），若数组很大或与 $lookup 组合，文档数量爆炸，内存与处理量剧增。何时反规范化：当关联查询高频、$lookup 成为瓶颈、数据量大使关联开销过大时，应反规范化——把关联字段冗余到主文档，用一次读取出全部数据，避免 $lookup 与 $unwind 的开销。反规范化牺牲一致性，换取读性能，适合读多写少场景。

$lookup 的"索引依赖"与 $unwind 的"文档爆炸"是两大陷阱。理解"关联无索引全表扫描、展开数组文档爆炸"，才能避免性能灾难。反规范化在高频读场景是 $lookup 的替代，但需维护冗余字段一致性。核心是权衡关联成本与一致性。

• 分片集群中聚合先在分片本地执行，再在 merge 分片合并
• $group/$sort 跨分片需合并部分，内存受限
• 100MB 内存限制与 allowDiskUse

在分片集群中，聚合管道是"分片感知"的：管道先在每个分片本地执行（下推），把可在分片完成的阶段（如 $match、本地 $group）在分片执行，再把部分结果发送到合并分片（merge）进行全局合并。$group/$sort 跨分片时，各分片先做局部分组/排序，merge 分片再合并各分片的局部结果做全局分组/排序，因此 $group/$sort 的合并数据在 merge 分片占用内存。内存限制：merge 分片处理全局聚合受 100MB 内存限制（默认），超限需 allowDiskUse 落盘；分片越多，合并的数据量与网络传输越大。跨分片聚合会显著增加内存与网络开销，应尽量让聚合在分片内完成（用分片键做分组键）。

分片聚合的核心是"分片本地执行 + merge 合并"。理解"分片下推 + merge 全局合并 + 100MB 内存限制"，是评估分片聚合的关键。跨分片聚合开销大，用分片键分组可减少合并。allowDiskUse 缓解内存压力。

• 优化器把 $match 提前、利用索引
• $sort 可用索引避免内存排序
• $project 提前裁剪、$group 前 $match 过滤

MongoDB 聚合优化器会对管道进行重排优化：把 $match 阶段提前到管道最前，使其能利用索引过滤并减少数据量；若 $sort 的字段有索引，则利用索引有序性避免内存排序；$project 尽量提前裁剪字段，减少后续阶段的内存与传输。开发者的写法要点：把 $match 放在管道最前（或至少 $group 之前），使过滤先于分组；$match 的字段应有索引（尤其前置的 $match）；$sort 若基于索引字段且紧跟 $match，可命中索引排序；$project 尽早裁剪非必要字段。遵循这些写法，能最大化优化器的作用，减少内存与延迟。

优化器是"自动重排"，但开发者的写法决定能否利用。理解"$match 前置用索引、$sort 用索引排序、$project 提前裁剪、$group 前过滤"，是写出高效聚合的关键。优化器自动做部分工作，但主动前置过滤与裁剪收益最大。

• 聚合默认 100MB 内存限制
• allowDiskUse 允许落盘到临时文件
• 分片集群落盘行为与单机差异

MongoDB 聚合管道默认有 100MB 内存限制，即聚合（尤其是 $group、$sort、$facet 等阻塞阶段）使用的内存超过 100MB 时，会报错（超出 100MB 限制）。启用 allowDiskUse 后，聚合可以把超出内存的数据写入磁盘临时文件，从而突破 100MB 限制，但会增加磁盘 IO 与延迟。$group/$sort 在内存不足时落盘，把部分数据写入临时文件后再合并。分片集群的差异：分片本地聚合与 merge 分片聚合各自有内存限制，merge 分片合并跨分片数据时同样受 100MB 限制，需 allowDiskUse 落盘；分片越多，合并数据量越大，落盘概率越高。allowDiskUse 是应对大聚合的兜底，但尽量通过前置过滤减少数据量。

100MB 内存限制与 allowDiskUse 是聚合内存管理的核心。理解"超限报错 + allowDiskUse 落盘 + 分片 merge 各自受限"，是评估大聚合的关键。优化应先减少数据量（$match 前置），再考虑落盘。分片集群的合并放大内存压力。

• $lookup 的 foreignField 需建索引
• $unwind 展开关联数组，文档数增加
• 组合优化：先过滤、控制数组规模

$lookup 的关联查询要求 from 集合的 foreignField 建立索引，否则退化为全表扫描，性能差。$lookup 与 $unwind 组合时，$lookup 把关联结果放入数组，$unwind 再把数组展开为多个文档。优化要点：确保 foreignField 有索引，使 $lookup 高效匹配；$unwind 前先 $match/$project 过滤不必要文档，减少展开量；若关联数组很大，$unwind 会产生大量文档，应先限制或避免展开；合理使用 $lookup 的 pipeline 语法在关联时过滤，减少关联结果。组合使用时，把能提前的过滤（$match）放在 $lookup/$unwind 之前，控制每步的数据量，并确保索引匹配。

$lookup+$unwind 的优化核心是"索引 + 控制文档爆炸"。理解"foreignField 索引 + $unwind 前过滤 + 关联时过滤"，是优化关联查询的关键。$unwind 前的数据量决定展开后规模，应尽早裁剪。索引是 $lookup 高效的前提。

• $merge 把聚合结果写回目标集合
• 支持按键 upsert 或更新
• 冲突与写入策略配置

$merge 是聚合管道中用于把聚合结果写回目标集合（可以是同一数据库或跨库）的阶段。它可以把聚合结果插入或更新到目标集合，按指定的匹配键（on）进行 upsert：若目标集合中已存在匹配键相同的文档，则更新（或按策略处理）；不存在则插入。$merge 的行为选项包括：whenMatched（匹配时更新/替换/合并）、whenNotMatched（不匹配时插入/丢弃/失败）。$merge 常用于物化视图、数据报表生成、ETL 等，把聚合结果持久化。注意 $merge 是写操作，会产生写入，需关注目标集合的性能与索引；若目标集合与源集合相同，需注意无限循环或冲突。

$merge 是"聚合结果持久化"的阶段。理解"按匹配键 upsert + whenMatched/whenNotMatched 策略"，是使用 $merge 的关键。它用于物化视图与 ETL，是聚合写回的能力。冲突处理通过策略配置控制。

• $unionWith 合并两个集合的结果
• $graphLookup 递归图遍历
• 分片集群下跨集合合并/关联的限制

$unionWith 用于把另一集合的文档合并到当前管道结果（类似 SQL UNION），要求两个集合的字段结构一致；$lookup 用于跨集合等值关联；$graphLookup 用于递归图遍历（如层级查询、树的递归关联），可跨集合做多层递归连接。组合用法：$unionWith 合并多集合数据，$lookup 做关联，$graphLookup 做递归层级。分片集群下的限制：$unionWith 的集合需有相同分片键或分布式；$graphLookup 递归可能跨分片产生大量查询，性能差；$lookup 跨分片关联时，若关联集合分片不同，需在 merge 分片合并，网络与内存开销大。跨集合合并/关联在分片集群中需注意分片键一致性与合并开销。

$unionWith/$lookup/$graphLookup 是跨集合操作的三类工具：合并、关联、递归。理解"合并需结构一致、递归开销大、跨分片关联需合并"，是评估性能的关键。分片集群中跨集合操作受分片键一致性与合并开销限制。

• $sort+$limit 只需保留前 N 条，避免全量排序
• 单独 $sort 需对全部数据排序
• 索引排序：$sort 字段有索引可避免内存排序

$sort 后接 $limit 时，MongoDB 可以执行 top-k 优化：只需维护前 k 条（k 为 limit 值）的最小/最大堆，而不需对全部输入排序，因此内存与耗时显著降低。单独 $sort 则必须对全部输入排序，内存与耗时长。索引利用上：若 $sort 的字段有索引，且 $match 过滤后能用索引有序返回，则 $sort 可完全利用索引有序性，避免内存排序（单独 $sort 用索引也无需排序）；但 $sort 字段无索引时，$sort 需内存排序，此时 $sort+$limit 的 top-k 优化价值更大（只需排前 k 条）。因此 $sort+$limit 是减少排序开销的手段，索引排序是避免排序的根本。

$sort+$limit 的 top-k 优化是"只取前 N 条避免全量排序"。理解"堆维护前 k 条"与"索引有序免排序"两点，是回答的关键。有索引时 $sort 免排序，无索引时 top-k 优化减量。两者是不同层面的优化。

• $lookup 单层等值关联
• $graphLookup 递归图遍历，支持多层层级
• 图遍历依赖索引与递归深度，性能边界

$lookup 与 $graphLookup 的差异在"层级"与"递归"。$lookup 做单层等值关联，把外部集合匹配文档放入数组，适合普通的一对一/一对多关联；$graphLookup 做递归图遍历，从一个起始文档出发，按关联字段递归查找（如组织树、分类层级、引用链），直到达到 maxDepth 或不再有匹配，适合层级/图查询。性能边界：$graphLookup 需在关联字段上建索引，且每个递归层级都发起查询，递归深度与分支数决定查询量，深度大或分支多时性能急剧下降；$lookup 相对简单，但无索引时也退化为全表扫描。适用场景：普通关联用 $lookup，层级/递归用 $graphLookup，但需控制递归深度并建立索引。

$lookup 单层 vs $graphLookup 递归是核心差异。理解"普通关联 vs 图遍历、递归深度与索引依赖"，是选型的关键。$graphLookup 适合层级查询但性能随深度劣化，需索引与深度控制。$lookup 适合简单关联。

• $densify 生成缺失的时间序列点
• $fill 填充缺失字段值
• 用于时间序列数据补全

$densify 用于在时间序列/数值序列中补全缺失的点：指定一个字段（如时间戳）和范围，$densify 会生成该范围内缺失的字段值，使序列连续（如每分钟一个点，缺失的间隔点被补上）。$fill 用于填充缺失字段值：对指定的字段，用指定方法（如线性插值、邻近值、固定值）填充缺失值。两者常配合用于时间序列分析：$densify 先生成缺失的时间点，$fill 再填充这些点的数值。$densify 需要指定字段、范围与步长；$fill 需指定方法（linear/nearest/locf/noop）。它们让时间序列数据完整、连续，便于聚合与可视化。

$densify 生成点、$fill 填值，是时间序列补全的两步。理解"$densify 补时间点 + $fill 补数值"的协作，是回答的关键。$densify 控制步长与范围，$fill 选插值/邻近方法。适用于不连续时间序列的补全。

• $unwind 默认丢弃数组为空或无字段的文档
• preserveNullAndEmptyArrays: true 保留这些文档
• 控制展开后文档是否保留

$unwind 用于展开数组字段，把数组中的每个元素作为独立文档输出。默认情况下，如果文档的数组字段为空数组或字段缺失（不存在），$unwind 会丢弃该文档（因为没有元素可展开）。设置 preserveNullAndEmptyArrays: true 后，这些文档会被保留（即使数组为空或字段缺失），输出的字段为 null 或空。该参数用于控制展开后是否保留"无元素"的文档。选择上：需要保留所有文档（即使无数组元素）时设为 true；只关心有数组元素的文档时用默认 false。它常与 $lookup 联用，处理关联结果为空的文档。

$unwind 的默认行为是丢弃空数组/缺失字段文档。理解"preserveNullAndEmptyArrays=true 保留空文档"，是控制展开结果的关键。与 $lookup 联用时，关联结果为空数组的文档默认被丢弃，需设 true 保留。理解该参数避免数据丢失。

• $bucket 按指定边界分桶
• $bucketAuto 按目标分桶数自动计算边界
• $bucketAuto 注意均匀分布与分桶数控制

$bucket 与 $bucketAuto 用于直方图分桶，把数据按字段值划分到多个桶。$bucket 需手动指定边界（boundaries）数组，把值落入对应区间；$bucketAuto 只需指定目标分桶数（buckets），MongoDB 自动计算边界，使各桶数据量尽量均衡（按数据分布划分）。$bucketAuto 的注意点：边界是自动计算的，为使分布均匀，它可能产生不等宽区间；分桶数 buckets 是目标值，实际可能因数据分布产生不同桶数；若数据高度集中，自动边界可能产生不均匀桶。设计时需理解 $bucketAuto 按数据分布自动定界，适合未知分布的数据；$bucket 手动定界适合已知边界。两者都支持对各桶做聚合输出。

$bucket 手动定界 vs $bucketAuto 自动定界是核心差异。理解"$bucketAuto 按数据分布自动计算边界、目标分桶数受分布影响"，是使用分桶的关键。自动分桶保证数据量均衡，但边界不可控；手动分桶边界可控。选型取决于是否知道边界。