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