嵌套字段查询慢的根本原因是点号路径无法走索引，MongoDB对user.address.city等查询默认不利用普通单字段索引，需索引键路径与查询路径完全一致且避免跨多层动态数组，否则易触发COLLSCAN。
嵌套字段查询慢，根本原因是点号路径无法走索引
MongoDB 对 user.address.city 这类嵌套字段的查询，默认不利用普通单字段索引。即使你对 address.city 创建了索引，db.users.find({"user.address.city": "Beijing"}) 仍可能触发集合扫描（COLLSCAN），尤其当文档量大、嵌套层级多时，性能断崖式下降。
真正起效的前提是：索引键路径必须与查询路径完全一致，且不能跨多层动态数组——比如 orders.items.name 中 items 是变长数组，索引效果会严重衰减。
- 用
explain("executionStats")检查是否出现"stage": "COLLSCAN"或nReturned远小于totalDocsExamined - 避免在查询中使用深层点号路径（如
a.b.c.d.e），超过 3 层就该警惕 - 复合索引必须包含完整路径前缀，例如要查
user.profile.settings.theme，索引得建在{"user.profile.settings.theme": 1}，而不是只建{"theme": 1}
数组内嵌套字段查询更危险：$elemMatch 是唯一可靠写法
当嵌套结构含数组（如 contacts: [{type: "email", value: "..."}]），直接写 {"contacts.value": "..."} 会匹配到任意数组元素，但 MongoDB 无法用索引高效定位——它得展开整个数组再逐个比对。
正确做法是强制用 $elemMatch 明确约束同一数组元素内的多个条件，否则索引形同虚设。
- ❌ 错误：
db.users.find({"contacts.value": "a@b.com", "contacts.type": "email"})—— 可能命中不同元素，无法用索引 - ✅ 正确：
db.users.find({contacts: {$elemMatch: {value: "a@b.com", type: "email"}}})—— 才能命中contacts.type_1_value_1复合索引 - 索引必须对应：
db.users.createIndex({"contacts.type": 1, "contacts.value": 1})，顺序不能颠倒
深度嵌套文档建议拆分，而非硬扛索引
不是所有嵌套都适合加索引。当一个文档里有 4 层以上嵌套 + 数组 + 高频更新字段（如 log.entries.timestamp），强行建索引会导致写放大严重，插入延迟飙升，得不偿失。
此时更务实的选择是重构数据模型：把高频查询/过滤的深层字段提到顶层，或单独建集合引用。
- 把
user.settings.theme提到user_theme字段，直接建索引{"user_theme": 1} - 将日志类数组（
events）拆到独立集合，用user_id关联，避免主文档膨胀 - 警惕 BSON 16MB 限制：深层嵌套 + 大数组容易触达上限，导致插入失败
explain 里 keyUpdates 和 docsExamined 比值暴露真实代价
很多人只看 millis，但真正反映嵌套查询健康度的是 executionStats 里的两个指标：
-
docsExamined越大，说明扫描越粗放；若接近集合总文档数，基本等于没索引 -
keyUpdates高（比如 > 0.5 ×nModified）意味着每次更新都在刷大量索引项，这是深度嵌套字段的典型副作用 - 如果
executionStats.nReturned / executionStats.totalDocsExamined
嵌套本身不是问题，问题是让查询引擎“猜不到”怎么快速定位——而索引和模型设计，本质都是在给它提供确定性路径。
