可以，但必须用完整点号路径，如"user.profile.age"，不能省略层级或使用通配符；索引键名严格区分大小写和点号位置；null、缺失或数组值会被跳过；超10层嵌套需实测性能。
深层嵌套字段能直接建索引吗？
可以，但必须用完整点号路径，不能省略中间层级。MongoDB 不支持“通配符式”的嵌套索引（比如 address.*），也不理解对象结构语义——它只认字符串路径。例如文档里有 {"user": {"profile": {"age": 25}}}，要加速 user.profile.age 查询，索引字段必须写成 "user.profile.age"，而不是 "user.profile" 或 "age"。
- 索引键名是严格字面量，大小写、空格、点号位置全敏感
- 如果字段有时是
null、有时缺失、有时是数组，该索引项会跳过（不影响查询正确性，但可能降低命中率）
- 多级嵌套超过 10 层时，索引构建和更新开销明显上升，需实测评估
复合索引中嵌套字段怎么排顺序？
和普通字段一样：按查询过滤条件的使用频率 + 选择性（cardinality）排序，高选择性字段靠前。但要注意，一旦嵌套字段出现在范围查询（$gt、$regex）或 $ne 中，它之后的所有字段在该索引中将无法用于范围裁剪。
null、有时缺失、有时是数组，该索引项会跳过（不影响查询正确性，但可能降低命中率） $gt、$regex）或 $ne 中，它之后的所有字段在该索引中将无法用于范围裁剪。
例如，你常查：{ "status": "active", "user.profile.score": { $gte: 80 }, "user.profile.tags": "vip" }
那么索引应建为：{ "status": 1, "user.profile.score": 1, "user.profile.tags": 1 }
而不是反过来——否则 score 的范围条件会让 tags 失去索引加速能力。
- 若嵌套字段参与
$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 为空
user.profile.age 值高度重复（如大量 0 或 null），索引区分度低，MongoDB 扫了 10 万条才凑够 100 条结果 $text 或 $regex（非前缀）导致索引失效，explain 里 indexBounds 为空 用 db.collection.explain("executionStats") 查看 nReturned 和 totalDocsExamined 的比值，若远小于 1%，就得重新评估字段选择性或考虑重构数据模型（比如把高频查询的嵌套字段提升一层）。
嵌套索引本身不难建，难的是判断它是否真被有效利用——执行计划里的数字比 createIndex 命令更值得盯紧。
