MongoDB支持用点号语法直接索引嵌套数组字段，如"users.score"；需严格匹配路径、大小写与层级，避免对数组建普通单字段索引以防膨胀，$elemMatch查询需复合索引且顺序一致，$size等操作符无法走索引。
用 dot 语法直接索引嵌套数组字段
MongoDB 支持对嵌套数组内部字段建索引，不需要手动“扁平化”结构。关键在于路径写法：用点号（.）逐级展开，数组字段名本身也要出现在路径里。比如文档是 { users: [ { name: "a", score: 95 } ] }，想加速查 users.score，索引字段就写 "users.score"，不是 "users..score"，也不是把数组展开成多个顶层字段。
- 数组字段在路径中只出现一次，MongoDB 自动处理多值展开（即每个数组元素都参与索引）
- 路径必须严格匹配字段名大小写和嵌套层级，
"Users.score"和"users.Score"是不同字段 - 如果数组是深层嵌套的，比如
data.items.tags，路径就得完整写成"data.items.tags"，漏掉任意一级都不生效
避免在数组字段上建单字段升序/降序索引（除非真需要排序）
对数组字段建 { "tags": 1 } 这类索引，会为数组每个元素单独生成索引条目——数据量大的时候，索引体积可能暴涨几倍，写入变慢，甚至触发 index key too large 错误。
- 纯查询过滤（如
{ tags: "mongodb" }）用{ "tags": 1 }没问题；但若同时要.sort({ tags: 1 })，才需要这个排序方向 - 更常见且安全的做法是建稀疏索引：
{ "tags": 1 }加sparse: true，跳过不含该字段或字段为null/空数组的文档 - 如果只用于
$elemMatch查询，索引路径应精确到子字段，比如{ "items.price": 1, "items.inStock": 1 }，而不是只索引"items"
$elemMatch 查询必须匹配索引前缀，否则走不了索引
当你用 { comments: { $elemMatch: { author: "x", votes: { $gt: 5 } } } } 查询时，MongoDB 只有在索引包含 "comments.author" 和 "comments.votes" 且二者构成连续前缀的情况下，才能高效使用索引。单独建 { "comments.author": 1 } 不够，它无法加速带两个条件的 $elemMatch。
- 正确做法是建复合索引：
{ "comments.author": 1, "comments.votes": 1 }（顺序不能颠倒，$elemMatch要求字段顺序与查询条件一致） - 如果查询还带了外层条件，比如
{ status: "published", comments: { $elemMatch: ... } }，索引应该把外层字段放前面：{ "status": 1, "comments.author": 1, "comments.votes": 1 } - 用
explain("executionStats")验证是否命中索引，重点看executionStages.stage是否为IXSCAN，以及nReturned是否接近nDocsExamined
数组索引不支持 $size、$slice 等操作符走索引
像 { tags: { $size: 3 } } 或 { profile: { $slice: -1 } } 这类查询，MongoDB 无法利用任何基于 "tags" 或 "profile" 的索引，只能全表扫描。这不是配置错误，是引擎限制。
-
$size是唯一一个明确被文档标注为“无法使用索引”的操作符 - 如果业务频繁查数组长度，考虑冗余一个
tagsCount字段，用应用层或变更流保持同步，然后对它建索引 -
$slice只影响返回结果投影，不参与查询条件，所以它本身不涉及索引问题；但如果你把它和未索引条件混用，容易误判性能瓶颈
addresses 当成对象建了 "addresses.city"，但它其实是数组）。跑一遍 db.collection.findOne({ "addresses.0.city": { $exists: true } }) 能快速验证路径有效性。 
