$elemMatch查询不走索引的根本原因是索引字段路径与查询路径未对齐，需确保索引显式包含数组字段（如{items:1}）或完整嵌套路径（如{'items.sku':1,'items.qty':1}），且所有条件能被同一数组元素同时满足。
绝大多数 $elemMatch 查询不走索引，根本原因不是语法写错，而是索引字段路径和查询路径没对齐——MongoDB 会严格比对字段名、嵌套层级、甚至数组位置是否可映射到索引键上。
为什么 $elemMatch 查询显示 COLLSCAN 而不是 IXSCAN
常见错误现象：db.orders.find({items: {$elemMatch: {sku: "A123", qty: {$gt: 5}}}}) 明明 items.sku 和 items.qty 都建了复合索引，explain("executionStats") 却返回 "stage": "COLLSCAN"。
这不是索引没建好，而是 MongoDB 认为：当前索引无法安全地缩小扫描范围。它要求 $elemMatch 中所有条件，必须能被「同一个数组元素」同时满足，且该元素的字段路径必须完整出现在索引定义中。
- 索引必须显式包含数组字段本身（如
items），不能只索引子字段（如items.sku单独建索引） - 如果索引是
{'items.sku': 1, 'items.qty': 1}，它本质上是两个独立单字段索引的组合，不构成支持$elemMatch的多键复合索引 - 真正有效的索引必须是
{items: 1}（自动转为多键）或更精确的{'items.sku': 1, 'items.qty': 1}—— 但注意：后者只有在items是对象数组（非标量数组）且每个元素都含这两个字段时才生效
检查索引路径与查询路径是否完全匹配
执行 db.orders.getIndexes() 查看实际索引定义，重点核对三点：
- 索引字段名是否和查询中
$elemMatch所在的数组字段**完全一致**（包括大小写、下划线、嵌套层级）；例如查询用profile.tags，索引就不能是tags或profile.metadata.tags - 如果数组里是嵌入文档，索引必须覆盖文档内字段的**全路径**，比如
comments.author.name，那索引就得是{'comments.author.name': 1}，不能省略comments.或author. - 避免“部分路径索引”：建了
{'items.price': 1}却对items数组整体做$elemMatch，MongoDB 不会把price索引复用到整个数组逻辑判断中
多键索引边界交集失效的典型场景
即使索引路径正确，$elemMatch 仍可能退化为低效扫描，关键看条件能否形成有效边界交集：
- 用
$elemMatch时，{items: {$elemMatch: {$gte: 90, $lte: 99}}}可推导出边界[90, 99]，能高效跳过无关数组项 - 但去掉
$elemMatch写成{'items': {$gte: 90, $lte: 99}}，MongoDB 就只能选一边界（如[90, Infinity]）扫描，大量无效匹配 - 更隐蔽的是字段类型混用：若
items数组里既有数字又有字符串，MongoDB 无法统一排序，多键索引边界计算失败，直接放弃使用索引
验证和修复的最小闭环操作
别猜，用 explain() 直接定位问题：
- 运行
db.orders.find({items: {$elemMatch: {sku: "A123", qty: {$gt: 5}}}}).explain("executionStats") - 检查输出中
"indexName"是否为空，"nReturned"是否远小于"totalDocsExamined"（说明扫了很多无效文档） - 确认
"executionStages"下是否有"stage": "IXSCAN"，且"keyPattern"和你预期的索引一致 - 如果仍不命中，临时加
.hint({items: 1})强制走多键索引，看是否从 COLLSCAN 变成 IXSCAN —— 若变换了，说明原索引定义有偏差，不是数据或查询逻辑问题
最常被忽略的一点：MongoDB 对数组字段建索引时，会自动识别为多键索引，但如果你删过重建、或用过 background: true，可能中途触发过索引状态异常；线上遇到诡异不走索引，优先跑一次 db.orders.reIndex()，比反复改查询更可靠。
