能，必须用完整点号路径且严格匹配字面量；如{"user.profile.settings.theme": "dark"}需建{"user.profile.settings.theme": 1}索引，缺一级或大小写/空格错误均失效。
深层嵌套字段能直接建索引吗？必须用完整点号路径
能，但只认字面量路径。比如文档结构是 {"user": {"profile": {"settings": {"theme": "dark"}}}}，要加速查询 {"user.profile.settings.theme": "dark"}，索引必须显式写成 {"user.profile.settings.theme": 1}。写成 {"user.profile": 1} 或 {"settings.theme": 1} 都无效——MongoDB 不解析对象结构，只做字符串路径匹配。
常见错误现象：
- 查询条件写了
{"user.profile.age": {$gte: 18}}，但索引建的是{"user.age": 1}，explain 显示stage: COLLSCAN - 字段名大小写不一致，如文档里是
"Profile"，索引却建了"profile"，索引完全不命中 - 路径中多了一个空格或点号位置错位，比如
"user. profile.age"（带空格），索引失效
数组字段里的嵌套对象怎么建索引？小心 multikey 膨胀
如果嵌套字段本身在数组里，比如 {"orders": [{"item": "book", "price": 29.99}, {"item": "pen", "price": 3.5}]}，对 "orders.price" 建索引会自动触发 multikey 索引（即使你没加 multikey: true）。MongoDB 会为每个数组元素生成独立索引条目。
这带来两个实际影响：
- 索引体积可能暴涨：100 个订单的文档，
"orders.price"索引就存 100 条记录；10 万文档 × 平均 50 个订单 → 索引条目超 500 万，内存和磁盘压力陡增 - 范围查询效率下降：对
"orders.price"做{$gte: 20}，MongoDB 得扫描所有匹配的数组元素索引项，不是单条记录比较 - 若同时查
"orders.item"和"orders.price"，别建两个单字段索引，优先考虑复合索引{"orders.item": 1, "orders.price": 1}，避免 multikey 叠加放大
聚合管道里 $match 走不走深层索引？只看是否裸用字段路径
能走，但有硬性限制：$match 阶段必须是“裸路径 + 原生操作符”，不能包裹在 $expr 里。
有效示例：
db.users.aggregate([
{ $match: { "user.profile.score": { $gte: 80 } } },
{ $project: { "user.profile.name": 1 } }
])
这个 $match 可以命中 {"user.profile.score": 1} 索引。
无效示例：
db.users.aggregate([
{ $match: { $expr: { $gte: ["$user.profile.score", 80] } } }
])
只要出现 $expr，整个条件强制全表扫描，explain 中 stage 一定是 COLLSCAN。同理，$function、$where 也彻底绕过索引。
为什么 explain 显示走了索引，但查询还是慢？重点看 indexKeysExamined vs docsReturned
这是最常被忽略的性能盲区。explain 输出里这两个值差距大，基本就是问题所在：
-
indexKeysExamined: 12000，nReturned: 12→ 索引区分度极低，比如大量文档的"user.profile.status"都是"pending"或null，索引扫了上万条才挑出 12 条 - 深层嵌套字段值重复率高时，索引几乎没剪枝能力；此时与其强依赖索引，不如重构数据模型：把高频过滤字段提到顶层，例如把
"user.profile.status"复制一份到"profile_status" - 超过 10 层嵌套的字段（如
"a.b.c.d.e.f.g.h.i.j.k"）建索引后，构建和更新开销显著上升，explain 中executionTimeMillis可能大部分花在索引维护上
真正卡住的往往不是“有没有索引”，而是“索引有没有实际筛掉数据”。检查 indexKeysExamined / nReturned 比值，大于 10 就该警觉。
