$all查询效率低因multi-key索引无法直接支持“元素交集”语义，导致大量文档需FETCH后FILTER；应将高选择性等值字段前置构建复合索引，或用partialFilterExpression缩小索引范围，并避免$all与排序组合引发内存溢出。
为什么 $all 查询会扫描大量文档却只返回几条
因为 $all 本身不改变索引使用逻辑，但多数人建的索引没覆盖数组字段的“元素交集”语义。MongoDB 对数组字段建索引时，会为每个元素单独生成索引项（multi-key index），而 $all: [a, b] 实际要求文档同时包含 a 和 b —— 这个“与”关系无法靠单字段索引高效完成，尤其当数组很长或匹配元素稀疏时，docsExamined 会远大于 nReturned。
- 典型现象：
explain("executionStats")显示totalDocsExamined: 2850000，nReturned: 12，totalKeysExamined却只有 3000 左右 —— 说明索引扫得少，但 fetch 后 filter 掉了绝大多数文档 - 根本原因：索引只帮它定位“含 a 的文档”或“含 b 的文档”，再用内存 filter 做二次筛选，不是真正意义上的“含 a 且含 b”的索引跳转
- 注意：
$all不能被单一字段索引“覆盖”，即使你对数组字段建了索引，也大概率触发IXSCAN → FETCH → FILTER流程
如何用复合索引让 $all 实际生效
关键不是给数组字段单独建索引，而是把 $all 所依赖的数组字段，和其他高选择性等值条件组合进同一个复合索引，并确保等值字段在前、数组字段在后。
- 错误写法：
db.items.createIndex({ tags: 1 })→ 只能加速{ tags: "x" }或{ tags: { $in: [...] } }，对$all效果有限 - 正确顺序：
db.items.createIndex({ status: 1, tags: 1 })，配合查询{ status: "active", tags: { $all: ["A", "B"] } } - 原理：MongoDB 先用
status快速缩小候选集，再在小范围内对tags做 multi-key 匹配，大幅降低docsExamined - 如果
status选择性差（比如 80% 文档都是 "active"），就换一个更严格的等值字段，例如category或带时间范围的created_at
partialFilterExpression 能解决稀疏 $all 场景
当只有部分文档的数组字段满足业务高频 $all 条件（比如仅 type: "product" 的文档才需要按 features 查），用 partialFilterExpression 缩小索引体积和扫描范围，比全量 multi-key 索引更高效。
- 示例：
db.items.createIndex({ features: 1 }, { partialFilterExpression: { type: "product" } }) - 效果：索引只包含
type: "product"的文档的features元素，避免为type: "log"等无关文档冗余建索引项 - 必须配合查询中显式带上
{ type: "product" }，否则 MongoDB 不会选这个 partial 索引 - 验证是否命中：
explain("executionStats")中planSummary应显示IXSCAN，且keysExamined ≈ docsExamined
别忽略 $all 与排序、分页的协同成本
$all 查询一旦加 .sort() 或 .limit()，很容易因索引无法覆盖排序字段，被迫走 IXSCAN → SORT → LIMIT，甚至退化成内存排序（memUsage 暴涨）。
- 错误组合：
find({ tags: { $all: ["A", "B"] } }).sort({ score: -1 }).limit(10)，即使有{ tags: 1, score: -1 }索引，multi-key 特性也会让 sort 阶段失效 - 安全做法：把排序字段放进复合索引最右侧，且确保前面所有字段都是等值匹配（包括
$all字段所在索引位置要能被完全利用） - 更稳方案：先用
$all+ 复合索引快速捞出 ID 列表，再用$in+ 另一个索引查详情并排序 —— 分两步换稳定性和可预测性 - 警惕
allowDiskUse: true日志：一旦出现，说明 sort 超出内存限制，性能已不可控
实际调优时最容易被忽略的一点：multi-key 索引的 keysExamined 可能远高于你预期的“文档数”，因为它统计的是“数组元素个数 × 匹配文档数”。一个含 50 个 tag 的文档匹配 $all: ["A","B"]，就会贡献 50 个索引键。所以 keysExamined 高不一定代表索引错，但 docsExamined / nReturned > 10 就一定得动手改索引结构。
