tags字段查询慢是因为未建多键索引，导致全表扫描；需创建{tags:1}索引，MongoDB自动转为multikey，且tags只能置于复合索引末位。
为什么 tags 字段用数组存，却查得慢？
因为默认没索引，MongoDB 对数组字段执行 $in、$all 或多条件匹配时，会全表扫描。哪怕只查 3 个标签，数据量一过百万，响应就卡在几百毫秒以上。
关键不是“能不能查”，而是“查几次后 CPU 就顶不住”。线上常见现象：监控里 queryExecutorStats 的 executionTimeMillisEstimate 突增，慢查询日志里全是带 tags: { $all: [...] } 的语句。
- 必须对
tags建多键索引（multikey index），不是普通索引 - 建索引命令是
db.collection.createIndex({ tags: 1 })—— MongoDB 自动识别数组并转为 multikey - 验证是否生效：用
db.collection.getIndexes()看multikey: true和multikeyPaths字段 - 别手动加
{ multikey: true }参数，MongoDB 8.0+ 会拒绝这种写法
$all 和 $elemMatch 选哪个？
取决于你要表达的逻辑：“必须同时包含所有标签”还是“某个元素要满足多个条件”。绝大多数标签过滤属于前者，直接用 $all 更轻量、更易命中索引。
$elemMatch 是为嵌套对象设计的，比如 { tags: { $elemMatch: { name: "vue", version: { $gte: "3.0" } } } } —— 这种场景才需要它。拿它来过滤纯字符串数组，不仅写法啰嗦，还可能绕过 multikey 索引的最优路径。
- 查“同时有 react 和 typescript”：用
{ tags: { $all: ["react", "typescript"] } } - 查“有 react 且创建时间早于 2023”：才考虑
$elemMatch，但这时tags应该是对象数组，不是字符串数组 -
$all在 multikey 索引下能用上IXSCAN；而错误套用$elemMatch可能退化成COLLSCAN
复合查询时，tags 索引还管用吗？
管用，但顺序很关键。MongoDB 复合索引遵循“前缀匹配”原则，tags 作为数组字段，只能放在复合索引的最后一位。
比如你常查 { status: "published", tags: { $all: [...] }, createdAt: { $gt: ... } }，那就得建 { status: 1, createdAt: 1, tags: 1 }。如果把 tags 放前面，整个索引对 status + createdAt 的筛选就失效了。
- multikey 字段不能做复合索引的前导字段（MongoDB 会报错或静默忽略）
- 用
explain("executionStats")检查indexKeysPattern和indexBounds，确认实际用了哪段索引 - 如果查询里还有正则（
$regex）或$text，它们会各自抢走索引主导权，tags索引大概率被跳过
标签太多导致文档膨胀，怎么压？
单个文档 tags 数组超过几百项，不仅占存储，还会拖慢复制集同步和 WiredTiger 压缩效率。不是靠删标签，而是从源头控制粒度。
真实业务里，“用户打的标签”和“系统预设的分类标签”应该分两个字段存：userTags（短生命周期、可重复、数量不定）和 categories（固定枚举、用于核心筛选）。前者可以不建索引，后者才建 { categories: 1 } 多键索引。
- 避免把搜索关键词、埋点事件名、版本号全塞进一个
tags数组 - 用
db.collection.updateMany(..., { $max: { tagCount: { $size: "$tags" } } })定期统计最大长度，设告警阈值 - WiredTiger 默认对数组压缩效果差，
tags超过 50 项后，每多一项带来的 BSON 开销呈非线性增长
tags 字段的更新操作（尤其是 $push、$addToSet）变重，高并发写入时容易成为瓶颈。要不要拆集合、加缓存，得看读写比——这点很容易被忽略。 
