MongoDB中多键索引（Multikey Index）的限制有哪些？

MongoDB多键索引自动创建且不可禁用，仅允许多个字段中至多一个为数组，unique约束跨文档不保数组内唯一，索引条目数随数组长度线性增长，需慎用并监控multiKeyPaths。

多键索引会自动创建，但不能手动指定

MongoDB 不提供 multikey 类型的显式索引声明。你调用 db.collection.createIndex({tags: 1}) 时，只要 tags 字段在任一文档中是数组，MongoDB 就自动将其设为多键索引——你无法绕过这个行为，也无法强制“关闭”多键特性。

常见错误现象：有人误以为加 {multikey: false} 能禁用，但该选项根本不存在；MongoDB 会忽略它，仍按多键逻辑处理。

• 判断依据是数据本身：哪怕 99% 文档的 tags 是字符串，只要有一条是 ["a", "b"]，整个索引就是多键
• 可通过 db.collection.getIndexes() 查看输出中的 "multikey": true 字段确认
• 一旦变成多键索引，就永久生效；即使后续所有文档都删掉数组值，索引类型也不会回退

复合多键索引禁止“多个数组字段”

这是最常踩坑的硬限制：在复合索引中，最多只能有一个被索引字段是数组。比如 {tags: 1, categories: 1} 要求任意文档都不能同时让 tags 和 categories 都是数组，否则插入失败或建索引报错。

错误信息典型为：Cannot create multi-key index with multiple array fields。

• 原因不是性能差，而是数学爆炸：两个长度分别为 m 和 n 的数组，会产生 m × n 条索引项，单文档就能撑爆内存
• 允许的组合：数组字段 + 普通字段（如 {tags: 1, price: -1}），或数组字段 + 嵌入文档中的标量字段（如 {"meta.status": 1, tags: 1}）
• 如果业务真需要多维数组查询，得拆成多个单数组索引，或改用聚合管道预计算

唯一多键索引的语义很特殊

unique: true 在多键索引下不保证“数组内元素唯一”，而是跨文档维度约束：不允许两个文档在该索引路径上产生完全相同的键值对组合。

举例：文档 A 的 roles: ["admin", "editor"] 和文档 B 的 roles: ["editor", "admin"] 在 {roles: 1} 唯一索引下是允许的——因为 MongoDB 对数组索引项排序后存储，两者都变成 ["admin", "editor"]，此时才触发唯一冲突。

• 数组内重复值会被去重：["a", "a", "b"] 只生成两个索引项 "a" 和 "b"
• 唯一性检查发生在每个索引键粒度，不是整个数组；所以 ["x"] 和 ["x", "y"] 不冲突
• 如果想约束数组内元素不重复，得靠应用层校验或使用 $addToSet 写入

索引膨胀和边界计算容易被低估

一个含 100 个元素的数组字段，会生成最多 100 个独立索引条目；若集合有百万文档且平均数组长度 50，索引体积可能远超原始数据本身。

更隐蔽的是查询边界行为：没有 $elemMatch 时，{ratings: {$gte: 3, $lte: 6}} 不会取交集区间 [3, 6]，而可能只用其中一个条件扫描——导致全量数组匹配而非精准定位。

• 务必用 $elemMatch 显式表达“同一个数组元素需同时满足多个条件”
• 避免在高频更新的长数组上建多键索引，写放大严重；考虑是否能用预聚合字段替代
• 索引键总长不能超 1024 字节（注意字符串数组里长文本的累积效应）

实际线上环境里，多键索引的问题往往不出现在创建时，而是在数据规模上来后才暴露——尤其是数组长度分布偏斜、或复合索引字段悄然变成数组时。留心 db.collection.stats().indexDetails 里的 multiKeyPaths 字段，比等报错再排查要快得多。