根本原因是$graphlookup默认仅在primary执行且依赖索引，未建{connecttofield:1, _id:1}复合索引会导致超时、空结果或递归卡在1层；需设maxdepth、restrictsearchwithmatch并避免跨库/sharded集合。
为什么 $graphLookup 在 MongoDB 6.0 副本集中可能不返回预期结果
根本原因不是副本集本身限制 $graphLookup，而是它默认只在当前节点（primary）执行聚合，且不自动处理跨分片或延迟读取场景；更关键的是，$graphLookup 要求被遍历的集合必须有索引支撑递归字段，否则会超时或只查一层。
常见错误现象：Exceeded time limit for $graphLookup、结果为空但数据明明存在、递归深度卡在 1 层。
- 确保
from集合中connectFromField和connectToField组合有复合索引，例如：db.nodes.createIndex({ "parentId": 1, "_id": 1 }) - 不要在
$graphLookup的from参数里写带数据库前缀的集合名（如"mydb.nodes"），只写集合名"nodes" - 副本集配置下，客户端连接字符串必须包含
readPreference=primary（默认满足），但若应用层显式设了secondary，则聚合可能路由失败或读到陈旧数据
如何正确写出可递归 3 层以上的 $graphLookup 查询
核心是控制 maxDepth、depthField 和终止条件。MongoDB 6.0 不支持无限递归，必须显式设 maxDepth，且实际可达深度还受内存与超时限制。
示例：从组织架构根节点出发查下属 3 级
{
$graphLookup: {
from: "employees",
startWith: "$managerId",
connectFromField: "managerId",
connectToField: "_id",
as: "subordinates",
maxDepth: 2,
depthField: "level",
restrictSearchWithMatch: { status: "active" }
}
}
-
maxDepth: 2表示最多再往下找 2 层（加上起始点共 3 层），不是“总共遍历 2 层” -
depthField: "level"会在每个结果子文档中注入数字字段，从 0 开始计数，便于后续过滤 -
restrictSearchWithMatch是每轮递归都生效的过滤器，不是只在第一层生效 - 若需排除自环（比如某人 managerId 指向自己），必须在
restrictSearchWithMatch中加{ _id: { $ne: "$managerId" } }
副本集中 $graphLookup 性能差、响应慢的直接优化点
慢通常不是网络问题，而是查询没走索引 + 每次递归全表扫描。副本集主节点负载高时，这个问题会被放大。
- 强制让
connectToField字段有独立索引：db.employees.createIndex({ "_id": 1 })（即使 _id 是主键，显式建索引可提升 lookup 效率） - 避免在
$graphLookup外层再套$unwind+$lookup，这会导致 N+1 查询；应把关联逻辑尽量收进同一个$graphLookup的restrictSearchWithMatch里 - 如果只需最深一层子节点（比如只查直属下级），别用
$graphLookup，改用普通$lookup+$expr，快一个数量级 - MongoDB 6.0 默认
maxTimeMS对聚合是全局的，建议在命令中显式加：{ maxTimeMS: 5000 }，防止长阻塞拖垮整个 primary
容易被忽略的兼容性陷阱：$graphLookup 在 6.0 副本集中的真实限制
它不支持在 from 集合上使用分片集合（sharded collection），哪怕你用的是副本集架构——只要该集合被 sharded 过，$graphLookup 就会报错 Cannot run $graphLookup on a sharded collection。
- 检查是否分片：
sh.status()或db.getSiblingDB("config").shards.find() - 副本集内跨数据库查询受限：
from必须和当前聚合所在数据库一致，不能写otherdb.collection -
startWith只接受单值或数组，不支持表达式链（如"$info.manager._id"要先用$addFields提前解出） - 结果数组里嵌套文档的字段顺序不保证稳定，别依赖
subordinates.0.name这种硬编码索引
真正难调的不是语法，是递归路径上的数据稀疏性——某个中间节点缺失 connectToField 值，整条分支就断了，而且不会报错，只会静默跳过。
