为什么MongoDB聚合管道中$search、含$text的$match必须放在第一阶段？

为什么包含$text的$match必须放在聚合管道首位 #

这是MongoDB文本索引的底层实现逻辑决定的：

• 全文检索依赖集合上预先创建的文本倒排索引，该索引是和原始集合的全量文档绑定的，只有在聚合管道第一阶段直接操作原始集合时，查询引擎才能正常调用文本索引完成匹配度计算、文档筛选。
• 如果$text之前存在其他管道阶段，管道此时输入的是经过前序阶段处理后的中间结果，不是原始集合的完整数据，无法和文本倒排索引做关联匹配，因此官方做了语法层面的强制限制。

对应优化方案 #

你原本的思路是对的，优先走name过滤减少扫描范围，实际可以用以下方案实现，完全不会损失查询效率：

方案1：合并过滤条件到第一个$match阶段 #

把name过滤条件和$text搜索写在同一个$match里，MongoDB的查询优化器会自动为该查询同时匹配文本索引和name字段的普通索引（需要提前给name字段建单键索引），相当于同时完成两个条件的过滤，不需要全集合扫描，性能比拆分两个$match更高。
优化后代码示例：

app.get('/', (req, res) => {
  db.collection('subs')
    .aggregate([
      {
        $match: {
          $text: { $search: 'honey' },
          name: { $in: ['Dexter', 'Prison Break', 'Breaking Bad'] }
        }
      }
    ])
    .toArray((err, result) => {
      if (err) {
        throw err;
      }
      res.json({
        length: result.length,
        body: { result },
      });
    });
});

方案2：使用Atlas Search的$search运算符 #

如果是使用MongoDB Atlas服务，可以替换原有$text搜索为更强大的$search运算符，该运算符没有必须放在管道首位的限制，支持任意位置的全文检索，同时查询性能、支持的检索能力都远高于旧版$text搜索。

极端场景补充方案 #

如果你的前置过滤逻辑非常复杂，无法合并到第一个$match里，可以先执行一次普通查询拿到符合前置过滤条件的文档_id列表，再把_id列表作为条件和$text并列放在第一个$match里，即可实现先过滤再走全文检索的效果。

内容的提问来源于stack exchange，提问作者moemous