MongoDB如何通过ObjectId引用实现跨集合关联查询？

你最初想到的两步查询思路本身没有问题，性能差的问题基本都是缺少对应索引、没有做投影优化导致的，优化后的两步查询是绝大多数场景下性能最高的实现，比聚合$lookup关联的效率更高。

前置索引配置 #

不管选择哪种实现，先建好以下索引，性能会有数量级提升：

• items集合：为name字段建单键索引，如果需要模糊查询可根据场景选择前缀正则匹配（可命中B树索引）或全文索引
• purchases集合：建userId + itemId的复合索引，两个查询方案都可以直接命中该索引，不需要回表扫描

方案1：优化版两步查询（仅需购买记录场景首选） #

这个方案的核心是把两次查询都优化为命中索引的窄查询，尽可能减少数据库扫描和数据传输量：

1. 第一步查询items集合时，只返回匹配名称的商品_id字段，通过投影过滤掉其他所有不需要的字段
2. 如果第一步返回的商品ID列表为空，直接返回空结果，不需要执行第二次查询
3. 第二步用$in操作符匹配商品ID，同时加上用户ID过滤，直接命中purchases的复合索引

参考Go实现代码：

// 第一步：根据商品名称查询匹配的商品ID列表
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

var itemIDs []primitive.ObjectID
// 加投影只返回_id字段，大幅降低传输开销
itemFindOpts := options.Find().SetProjection(bson.M{"_id": 1})
itemCursor, err := itemsCollection.Find(ctx, bson.M{
    "name": bson.M{"$regex": keyword, "$options": "i"}, // 按需替换为精确匹配/前缀匹配
}, itemFindOpts)
if err != nil {
    // 错误处理
}
defer itemCursor.Close(ctx)

for itemCursor.Next(ctx) {
    var tmp struct{ Id primitive.ObjectID `bson:"_id"` }
    if err := itemCursor.Decode(&tmp); err != nil {
        // 错误处理
    }
    itemIDs = append(itemIDs, tmp.Id)
}
// 无匹配商品直接返回
if len(itemIDs) == 0 {
    return []Purchase{}, nil
}

// 第二步：查询指定用户对应商品的购买记录
purchaseFilter := bson.M{
    "userId": targetUserID,
    "itemId": bson.M{"$in": itemIDs},
}
var purchases []Purchase
if err := purchasesCollection.Find(ctx, purchaseFilter).All(ctx, &purchases); err != nil {
    // 错误处理
}
return purchases, nil

这个方案的优势：

• 两次都是MongoDB优化最成熟的简单CRUD查询，命中索引后延迟极低
• 逻辑灵活，方便加分页、排序、额外过滤条件
• 不存在聚合管道的内存限制、结果大小限制问题，超大数据量下稳定性更好

方案2：$lookup聚合单次查询（需要同时返回商品详情场景首选） #

如果你需要在返回购买记录的同时，直接带出对应商品的名称、价格等字段，不需要额外组装数据，可以用聚合管道实现关联查询。注意不要把商品名称的过滤放在$lookup之后，否则会先拉取用户所有购买记录关联的商品再过滤，性能很差，正确写法是把商品过滤逻辑放在$lookup的嵌套管道中，关联阶段就完成过滤：

参考Go实现代码：

pipeline := mongo.Pipeline{
    // 第一阶段：先过滤指定用户的购买记录，直接命中purchases的userId索引
    {{"$match", bson.M{"userId": targetUserID}}},
    // 第二阶段：关联items集合，关联时直接过滤匹配名称的商品
    {{"$lookup", bson.M{
        "from":         "items",
        "localField":   "itemId",
        "foreignField": "_id",
        "as":           "item",
        "pipeline": bson.A{
            {"$match": bson.M{"name": bson.M{"$regex": keyword, "$options": "i"}}},
            {"$project": bson.M{"name": 1, "price": 1, "lastBought": 1}}, // 只返回需要的商品字段
        },
    }}},
    // 第三阶段：过滤掉没有匹配到对应商品的购买记录
    {{"$match", bson.M{"item": bson.M{"$ne": bson.A{}}}}},
    // 第四阶段：把单元素的item数组拆为对象
    {{"$unwind", "$item"}},
}
// 数据量较大时可加SetAllowDiskUse(true)避免内存限制
aggOpts := options.Aggregate().SetAllowDiskUse(false)
cursor, err := purchasesCollection.Aggregate(ctx, pipeline, aggOpts)
if err != nil {
    // 错误处理
}
defer cursor.Close(ctx)
// 定义返回结构接收带商品信息的结果即可

这个方案的注意点：

• 性能比优化后的两步查询低15%~30%，优势是单次查询即可拿到完整关联数据
• 必须保证items的_id（默认自带索引）、name字段有索引，purchases的userId字段有索引
• 单批次聚合结果不能超过16MB，超大规模数据集需要注意分页

避坑提示 #

• 不要盲目迷信“单次查询一定比多次查询快”：MongoDB的$lookup本质就是在数据库内部实现了和两步查询一样的关联逻辑，加上聚合管道本身的阶段开销，性能通常低于手动执行的两次简单索引查询
• 模糊查询如果是前后通配（比如%关键词%）无法命中B树索引，这类场景如果查询频率高，建议搭配全文索引或者专用搜索引擎实现
• 不要在purchases集合中冗余存储商品名称、价格这类易变字段，除非你能接受数据不一致的问题，或者有完善的异步同步机制

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