直接为高基数数组字段建普通多键索引会导致写入性能骤降，因其为每个数组元素生成独立索引项，大幅增加I/O、B树分裂和内存压力；应改用稀疏+长度限制索引，并配合$elemMatch查询以确保命中。
直接对高基数数组字段（比如 tags、features、用户行为序列）建普通多键索引，是写入性能骤降最常见的设计误操作——不是没建索引，而是索引建得太“勤快”了。
为什么数组索引会让写入变慢？
MongoDB 对数组字段建 { field: 1 } 索引时，会为每个元素生成一条独立索引条目。一个文档含 50 个标签，就写入 50 条索引记录；1000 次插入 × 平均 30 元素 = 每秒额外写入数万索引项。这不仅放大磁盘 I/O，还会加剧 B 树分裂和内存缓存压力。
常见现象包括：
-
db.collection.stats()显示size小但totalSize异常大（索引体积远超数据本身） - 写入吞吐在加索引后下降 40%+，尤其在批量导入或高并发更新时
-
mongostat中idx列数值持续高于qr/qw，说明索引维护已成瓶颈
用稀疏 + 长度限制索引替代普通多键索引
不是否定多键索引，而是控制它“在哪建、为谁建”。关键参数只有两个：sparse: true 和 partialFilterExpression。
实操建议：
- 先确认字段是否真需要索引：如果 90% 查询只查
{ tags: "x" }这种存在性，且数组平均长度 ≤ 3，可暂不建索引 - 对
tags字段建索引时，明确拒绝长数组：db.items.createIndex({ tags: 1 }, { sparse: true, partialFilterExpression: { "tags.9": { $exists: false } } })—— 这表示只索引长度 ≤ 10 的数组（"tags.9"不存在即索引到第 0–9 位） - 避免在
logs、events类集合上对数组建索引；改用预聚合字段，如has_error: true、event_types: ["click", "submit"]再分别建单字段索引
$elemMatch 不是银弹，但必须配合索引使用
即使建了稀疏+长度限制索引，查询写法不对，照样触发全量多键展开。MongoDB 优化器对 { tags: "python" } 的执行路径不可控，但对 { tags: { $elemMatch: { $eq: "python" } } } 会强制走索引范围扫描。
注意边界条件：
-
$elemMatch在单条件场景下（仅匹配一个值）与直接匹配语义等价，但执行计划更稳定 - 复合查询中必须显式使用：
{ tags: { $elemMatch: { $gte: "a", $lt: "z" } } }才能命中索引；写成{ tags: { $gte: "a", $lt: "z" } }会失效 - 如果业务允许，优先用预计算布尔字段替代数组查询，例如写入时设
has_tag_python: true，再为该字段建轻量索引
监控和验证索引是否真正生效
别只看 getIndexes() 返回了什么，要验证它是否被实际使用。
每上线一个新索引，必须跑两步：
- 用
db.collection.explain("executionStats").find({ tags: { $elemMatch: { $eq: "mongodb" } } })查看executionStats.nReturned和totalKeysExamined的比值——理想应接近 1:1，若后者是前者的百倍，说明索引仍过密或未命中 - 对比写入压测：用相同数据集，分别测试有/无该索引时的
insertMany吞吐（单位：docs/sec），下降超过 15% 就得重新评估 - 定期检查
db.collection.stats().indexDetails中各索引的keysPerDocument均值，长期高于 5 就该触发告警
最易被忽略的一点：索引策略必须和写入逻辑对齐。比如你用 partialFilterExpression 排除了长度 >10 的数组，但业务代码仍在往 tags 里塞 50 个值——那这些文档根本不会进索引，查询自然“找不到”，而不是“找得慢”。索引不是补丁，是 schema 设计的一部分。
