数组字段查询慢且普通索引无效，是因为mongodb对数组字段需建multikey索引；若索引路径与查询路径不匹配（如查items.price却只索引items）、未触发multikey标记、或复合查询缺少对应复合索引，均导致全表扫描。
为什么数组字段查得慢，加普通索引没用
MongoDB 对数组字段的索引行为和普通字段不同：只要文档中某个字段是数组，且你对该字段建了索引，MongoDB 就会自动创建 multikey 索引（无需显式声明）。但问题在于——如果你对数组里的嵌套对象字段（比如 tags.name 或 items.price）直接建索引，而没确认数组层级是否被正确识别，查询时可能完全不走索引。
常见错误现象：db.collection.find({ "items.price": { $gt: 100 } }) 执行很慢，explain("executionStats") 显示 "stage": "COLLSCAN"，说明根本没命中索引。
- 必须确保索引路径能精确匹配查询路径，比如查
items.price，索引就得建在items.price，而不是只建在items - 如果
items是数组，且每个元素是对象，items.price自动触发 multikey；但如果items本身是空数组或缺失，该文档仍会被纳入 multikey 索引范围，可能影响选择性 - 一个索引最多只能有一个 multikey 路径（即最多一个数组字段参与），否则 MongoDB 拒绝创建（4.2+ 版本会报错
"Multi-key indexes do not support multiple array fields"）
如何确认并强制启用 multikey 索引
MongoDB 大部分情况下会自动识别 multikey，但某些场景（如集合初始为空、或数组字段后期才出现）会导致索引未标记为 multikey，进而使查询失效。不能只看 createIndex 是否成功，要看实际状态。
检查方式：db.collection.getIndexes()，关注返回中每个索引的 "multikey": true 字段；或者用 db.collection.stats().indexDetails 查看详细标记。
- 如果发现本该 multikey 的索引显示
"multikey": false，说明当前数据不足以触发自动识别——插入一条含非空数组的样例文档再运行db.collection.reIndex()（注意：生产慎用，会锁表） - 不要手动设置
multikey: true选项传给createIndex()，MongoDB 不接受该参数，会报错"unrecognized field 'multikey'" - 复合索引中，只要任意一个字段路径指向数组内容（如
{"items.qty": 1, "status": 1}），整个索引就是 multikey，即使status是字符串
嵌套数组 + $elemMatch 查询必须配对建索引
当使用 $elemMatch 同时约束多个字段（比如找 items 中既满足 price > 100 又满足 inStock: true 的元素），普通单字段索引无效，必须建覆盖全部条件的复合索引。
一款AI工具，主要用于自动分析崩溃并修复错误。监控 Cloudflare D1 崩溃报告，进行去重和 Codex 5.3 High 分析，生成修复并创建...，适合需要提升相关任务效率的用户。
错误示例：db.orders.find({ items: { $elemMatch: { price: { $gt: 100 }, inStock: true } } })，若只对 items.price 建索引，查询仍全表扫。
- 正确索引：
db.orders.createIndex({ "items.price": 1, "items.inStock": 1 }) - 顺序很重要：把带范围操作（
$gt,$lt）的字段放后面，等值字段（inStock: true）放前面，利于索引截断 - 如果查询还带顶层条件（如
status: "paid"），可扩展为{"status": 1, "items.inStock": 1, "items.price": 1}，但注意：multikey 部分仍只能有一个数组路径（这里是items.*），所以status放最前是安全的
性能陷阱：$all 和无序数组匹配难优化
$all 查询（如 { tags: { $all: ["urgent", "backend"] } }）看起来简单，但底层需对每个数组元素做多次匹配，即使有索引也常退化为扫描大量键。
更糟的是，如果数组元素顺序不确定（比如用户随意添加标签），$all 无法利用范围索引加速，且 multikey 索引对它的选择性通常很低。
- 避免对长数组字段（如
tags平均长度 > 10）直接建tags单字段索引，它会产生大量索引条目，拖慢写入 - 若必须支持多标签交集查询，考虑预计算组合哈希（如
tagSetHash: "backend,urgent"）并建唯一索引，或改用聚合管道 +$setIntersection在应用层过滤 -
$size查询（如{ tags: { $size: 2 } }）完全不能走索引，永远 COLLSCAN，务必提前规避
multikey 索引不是银弹——它让数组可查，但也让索引体积膨胀、写入变慢、内存占用升高。真正关键的，是让查询路径和索引路径严格对齐，并时刻用 explain() 验证是否真的在用索引。
