可以，但必须用完整点号路径，如"user.profile.age"，不能省略层级或使用通配符；索引键名严格区分大小写和点号位置；null、缺失或数组值会被跳过；超10层嵌套需实测性能。
深层嵌套字段能直接建索引吗？
可以，但必须用完整点号路径，不能省略中间层级。MongoDB 不支持“通配符式”的嵌套索引（比如
），也不理解对象结构语义——它只认字符串路径。例如文档里有
，要加速
查询，索引字段必须写成
，而不是
或
。
索引键名是严格字面量，大小写、空格、点号位置全敏感
如果字段有时是
、有时缺失、有时是数组，该索引项会跳过（不影响查询正确性，但可能降低命中率）
多级嵌套超过 10 层时，索引构建和更新开销明显上升，需实测评估
复合索引中嵌套字段怎么排顺序？
和普通字段一样：按查询过滤条件的使用频率 + 选择性（cardinality）排序，高选择性字段靠前。但要注意，一旦嵌套字段出现在范围查询（
、
）或
中，它之后的所有字段在该索引中将无法用于范围裁剪。
例如，你常查：
那么索引应建为：
而不是反过来——否则
的范围条件会让
失去索引加速能力。
若嵌套字段参与
，仍算等值匹配，不影响后续字段
数组字段（如
）建索引后，会为每个元素生成独立索引条目，易导致索引膨胀
聚合管道里用
走不走深层索引？
会，但仅限于最前面的
阶段，且条件必须是单层谓词（不能包裹在
里）。比如：
这个
可以命中
索引。但如果写成：
就完全不走索引——
强制全表扫描计算。
后续阶段（如
）若用到已索引字段，也不会复用前面的索引；需要单独建含排序字段的索引
的本地字段如果也是深层嵌套，同样需要对应索引，否则关联性能极差
为什么
显示走了索引，但查询还是慢？
常见原因不是索引没建对，而是“索引扫描量”远大于“实际返回量”。比如：
文档中
值高度重复（如大量 0 或 null），索引区分度低，MongoDB 扫了 10 万条才凑够 100 条结果
查询同时带多个嵌套字段条件，但只给其中一部分建了索引，其余靠内存过滤
使用了
或
（非前缀）导致索引失效，explain 里
为空
用
查看
和
的比值，若远小于 1%，就得重新评估字段选择性或考虑重构数据模型（比如把高频查询的嵌套字段提升一层）。
MongoDB For Windows v3.5.4
MongoDB For Windows v3.5.4
下载
嵌套索引本身不难建，难的是判断它是否真被有效利用——执行计划里的数字比 createIndex 命令更值得盯紧。
address.*{"user": {"profile": {"age": 25}}}user.profile.age"user.profile.age""user.profile""age"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 }scoretags$inuser.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$lookupexplain()user.profile.age$text$regexindexBoundsdb.collection.explain("executionStats")nReturnedtotalDocsExamined