应避免对高基数数组字段建普通多键索引，改用稀疏索引+长度限制（如{tags:1},{sparse:true,partialFilterExpression:{"tags.9":{$exists:false}}}），并查询时优先使用$elemMatch而非直接匹配数组。
多键索引导致查询变慢怎么办
当文档中数组字段元素过多（比如一个 tags 字段包含上百个字符串），MongoDB 会为每个元素单独生成索引条目，索引体积爆炸式增长，查询反而变慢。这不是“索引没建”，而是“索引建得太密”。
- 先确认是否真用了多键索引：
db.collection.getIndexes()查看索引定义里是否有arrayField: 1这类声明 - 用
db.collection.explain("executionStats").find({ arrayField: "x" })看totalKeysExamined是否远大于nReturned—— 如果是，说明索引扫描了大量无效键 - 避免对高基数数组字段（如日志标签、用户行为序列）直接建普通多键索引
稀疏索引 + 数组长度限制能省多少空间
不是所有文档都有该数组，也不是所有数组都值得索引。对 tags 这类字段，80% 的文档可能只有 1–3 个标签，但 5% 的文档塞了 50+ 个，它们拖垮了整个索引效率。
- 加
sparse: true：只索引非空、非 null 的数组字段，跳过缺失该字段的文档 - 加
partialFilterExpression控制索引范围，例如只索引长度 ≤ 10 的数组：{ "tags.9": { $exists: false } } - 组合使用：
db.items.createIndex({ tags: 1 }, { sparse: true, partialFilterExpression: { "tags.9": { $exists: false } } }) - 实测：某电商商品集合中，
features数组平均长度 27，加长度限制后索引体积从 4.2GB 降到 0.8GB
查询时用 $elemMatch 而不是直接匹配数组
直接写 { tags: "python" } 会触发多键索引全量展开；而 $elemMatch 让 MongoDB 明确知道你只关心“单个元素满足条件”，优化器更可能选对执行计划。
- ✅ 推荐：
db.posts.find({ tags: { $elemMatch: { $eq: "mongodb" } } }) - ❌ 避免：
db.posts.find({ tags: "mongodb" })（语义相同，但执行路径更不可控） - 复合场景下，
$elemMatch还能配合其他条件，比如：{ tags: { $elemMatch: { $gt: "a", $lt: "z" } } } - 注意：如果只是查“是否包含某值”，且数组长度普遍很短，两者性能差异不大；但一旦数组变长或索引膨胀，
$elemMatch更稳定
替代方案：预计算标签组合或改用位图索引
当数组元素本身可枚举、总量有限（比如 100 个固定标签），硬建多键索引就是设计错误。这时候应该把“数组存在性”转成字段存在性。
- 在写入时预计算布尔字段：
has_tag_mongodb: true、has_tag_python: true，再为这些字段建单字段索引 - 或用整数位图（如
tag_bitmap: 0b101000...），配合$bitsAllSet查询，适合标签总数 - 代价是写入逻辑变重，但读取极快，且索引体积恒定 —— 对高频查询、低频写入的场景（如内容分类页）非常划算
- 别忘了清理旧索引：
db.collection.dropIndex("tags_1")，否则写放大依然存在
