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 字段，比等报错再排查要快得多。
