MongoDB自动将含数组字段的索引标记为多键索引（multikey: true），该标记不可逆，导致复合索引右侧字段范围扫描失效、索引体积暴涨、写入放大及查询效率下降。
多键索引自动触发的条件和隐式行为
MongoDB 一旦检测到文档中被索引的字段是数组（哪怕只有一条文档、一个元素），就会将该索引标记为多键索引（
）。这个标记不可逆，即使后续所有文档都改成非数组值，索引仍保持多键状态。它不报错，但会显著影响查询计划：例如
和
在复合索引中若左侧字段是多键，右侧字段的范围扫描可能失效。
多键索引由服务器自动设置，无法手动关闭或“降级”
使用
查看
字段确认
复合索引中只要任意一个字段是数组，整个索引即为多键——不是按字段粒度隔离的
数组字段索引性能差的根源在哪？
根本问题不是“数组不能建索引”，而是 MongoDB 对每个数组元素单独生成索引条目，导致：
索引体积暴涨（N 元素 × 文档数）
写入放大（插入/更新一个数组要写 N 条索引记录）
查询时
显示
远小于
，说明大量索引条目被跳过
常见误操作：
对高频更新的标签数组（如
）直接建
在复合索引里把数组字段放在前面，例如
，导致
的排序失效
绕过多键限制的三种可行路径
不是所有数组都需要被索引。优先评估是否真需要“按数组元素查”，再选方案：
MongoDB For Windows v3.5.4
MongoDB For Windows v3.5.4
下载
若只需判断“是否包含某值”，用
+ 单字段索引即可，无需改变结构
若需精确匹配整个数组（顺序+元素全等），把数组转成不可变字符串哈希，例如新增字段
，对该字段建唯一索引
若必须支持“数组内多个条件组合查询”（如 tags 包含 A 且 status 是 active），改用反范式化：把常用组合预计算为布尔字段，例如
,
，再建复合索引
验证索引是否真正生效的关键检查点
别只看
，要结合查询执行计划：
运行
检查
是否为
（而非
）
注意
是否接近
；如果前者是后者的几十倍，说明索引选择效率极低，大概率是多键膨胀所致
对复合查询，用
强制指定索引，对比耗时变化，避免优化器选错
数组字段的索引代价容易被低估——一条含 50 个标签的文档，就向索引里塞进 50 条记录。上线前务必用真实数据量级压测
和写入延迟。
multikey: true$gt$ltdb.collection.getIndexes()"multikey": trueexplain("executionStats")nReturnedtotalDocsExaminedtags: ["a", "b", "c"]{ tags: 1 }{ tags: 1, createdAt: -1 }createdAttags: { $in: ["x"] }tagsHash: "sha256:abc123"hasTagA: truehasTagB: false{ hasTagA: 1, status: 1 }getIndexes()db.collection.find({ tags: "x" }).explain("executionStats")executionStages.stageIXSCANCOLLSCANexecutionStages.keysExaminednReturnedhint()keysExamined