如何通过 MongoDB 的 mgo 驱动高效实现文档间关联而非使用 DBRef？

本文共计1017个文字，预计阅读时间需要5分钟。

原文：

MongoDB 原生不支持传统关系型数据库的 JOIN 语句，但自 3.2 版本起引入的 $lookup 聚合阶段，为跨集合关联查询提供了强大、高性能的解决方案。而 mgo（尽管已归档，但在大量遗留项目中仍在使用）完全支持该特性。值得注意的是：DBRef 是一种语义化约定而非 MongoDB 内建功能，它缺乏索引支持、无法被聚合管道直接解析，且 mgo.FindRef 会触发多次独立查询，导致 N+1 查询问题——这正是你代码中“try 10000 times inserts”后性能骤降的根本原因。

✅ 推荐方案：手动引用 + $lookup（单次聚合）

首先重构数据模型，摒弃 mgo.DBRef 和冗余字段，采用轻量、可索引的 bson.ObjectId 字段显式存储关联 ID：

type User struct { ID bson.ObjectId `bson:"_id" json:"id"` Name string `bson:"name" json:"name"` } type Post struct { ID bson.ObjectId `bson:"_id" json:"id"` UserID bson.ObjectId `bson:"userid" json:"userid"` // 手动引用，非 DBRef Title string `bson:"title" json:"title"` }

插入示例：

userID := bson.NewObjectId() user := &User{ID: userID, Name: "test"} err := session.DB("mydb").C("users").Insert(user) if err != nil { panic(err) } post := &Post{ID: bson.NewObjectId(), UserID: userID, Title: "test manual reference"} err = session.DB("mydb").C("posts").Insert(post)

执行左连接（等价于 LEFT JOIN posts ON users._id = posts.userid）：

// 在 users 集合上执行聚合，将匹配的 posts 关联到每个 user 的 "posts" 字段 pipeline := []bson.M{ { "$lookup": bson.M{ "from": "posts", // 关联的目标集合 "localField": "_id", // 当前集合（users）的字段 "foreignField": "userid", // 目标集合（posts）的字段 "as": "posts", // 输出数组字段名 }, }, // 可选：仅返回有 post 的用户（INNER JOIN） // {"$match": bson.M{"posts.0": bson.M{"$exists": true}}}, } var result []bson.M err := session.DB("mydb").C("users").Pipe(pipeline).All(&result) if err != nil { panic(err) } // result 示例结构见下文，可直接 JSON 序列化或映射到结构体

⚠️ 其他方案对比与注意事项

• 嵌入式设计（Embedding）：若 Post 数据量小、更新频率低、且与 User 强绑定（如用户个人简介、头像元数据），可考虑将 Post 作为子文档嵌入 User 结构。但对高写入、多读取场景（如博客系统），分离集合 + $lookup 更具扩展性。

• 避免 N+1 查询：你原代码中的 for _, m := range posts { db.FindRef(m.ref).One(...) } 会在循环中发起 N 次独立查询，网络开销和延迟呈线性增长。$lookup 在服务端一次性完成关联，是质的提升。

• mgo 已归档，生产环境建议升级：mgo 自 2019 年起不再维护。新项目请使用官方驱动 mongo-go-driver，其对聚合、事务、连接池的支持更完善，API 更现代。

✅ 总结

方案	性能	可维护性	是否推荐	说明
DBRef + FindRef	❌ 差	❌ 低	❌ 否	多次查询、无索引、语义模糊
手动引用 + $in + 双查	⚠️ 中	⚠️ 中	⚠️ 慎用	需两次查询，适合小批量数据
手动引用 + $lookup	✅ 优	✅ 高	✅ 强烈推荐	单次聚合、可索引、符合 MongoDB 设计哲学

遵循“以查询模式驱动数据建模”的原则，优先让数据结构适配高频查询路径——这才是 MongoDB 高效使用的底层逻辑。