如何通过建立深层嵌套路径索引优化MongoDB中复杂对象的属性查询？

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

例如，你经常查询：

• 若嵌套字段参与 $in，仍算等值匹配，不影响后续字段
• 数组字段（如 user.hobbies）建索引后，会为每个元素生成独立索引条目，易导致索引膨胀

聚合管道里用 $match 走不走深层索引？ 会，但仅限于最前面的 $match 阶段，且条件必须是单层谓词（不能包裹在 $expr 里）。比如：

[ { $match: { "user.profile.age": { $gte: 18 } } }, { $addFields: { ... } } ]

这个 $match 可以命中 {"user.profile.age": 1} 索引。但如果写成：

{ $match: { $expr: { $gte: ["$user.profile.age", 18] } } }

就完全不走索引——$expr 强制全表扫描计算。

• 后续阶段（如 $sort）若用到已索引字段，也不会复用前面的索引；需要单独建含排序字段的索引
• $lookup 的本地字段如果也是深层嵌套，同样需要对应索引，否则关联性能极差

为什么 explain() 显示走了索引，但查询还是慢？ 常见原因不是索引没建对，而是“索引扫描量”远大于“实际返回量”。比如：

• 文档中 user.profile.age 值高度重复（如大量 0 或 null），索引区分度低，MongoDB 扫了 10 万条才凑够 100 条结果
• 查询同时带多个嵌套字段条件，但只给其中一部分建了索引，其余靠内存过滤
• 使用了 $text 或 $regex（非前缀）导致索引失效，explain 里 indexBounds 为空

用 db.collection.explain("executionStats") 查看 nReturned 和 totalDocsExamined 的比值，若远小于 1%，就得重新评估字段选择性或考虑重构数据模型（比如把高频查询的嵌套字段提升一层）。

嵌套索引本身不难建，难的是判断它是否真被有效利用——执行计划里的数字比 createIndex 命令更值得盯紧。