多条件查数组字段慢是因为mongodb无法高效用普通索引定位数组元素，需建复合索引{"attributes.name":1,"attributes.value":1}（4.2+），并确保等值字段前置；避免$unwind，优先冗余高频字段为独立可索引字段。
多条件查数组字段时为什么慢得像卡住
因为 model.attributes 是数组，而你用了 $elemMatch 或直接点查 attributes.name、attributes.value，MongoDB 默认没法用普通索引高效定位——它得把每个文档的整个数组展开扫描一遍。
常见错误现象：explain() 显示 nReturned 很小但 totalDocsExamined 巨大；查询耗时随数据量非线性上涨；加了单字段索引也没用。
- 必须把数组结构“扁平化”成可索引的路径：比如用
attributes.name和attributes.value组合，而不是只索引attributes - 如果数组里每项是 {name: "color", value: "red"} 这种键值对，别用
$where或聚合管道提前过滤——先靠索引缩小范围，再在内存里筛 - 注意 MongoDB 版本：4.2+ 才支持对数组内嵌对象字段建复合索引（如
{"attributes.name": 1, "attributes.value": 1}），低版本只能建多键索引，效果打折
复合索引怎么写才真正生效
不是字段列出来就行。MongoDB 对数组字段建复合索引时，会为数组中**每一项**生成一个索引条目，但只有前导字段能用于范围扫描——后面字段只在等值匹配时起效。
假设你要查 { "attributes.name": "size", "attributes.value": { $gt: "M" } }，这个查询无法用 {"attributes.name": 1, "attributes.value": 1} 索引做范围扫描，因为 name 是等值，value 是范围，但数组索引的结构决定了：它实际存的是多个 (size, S)、(size, M)、(size, L) 条目，无法跳过中间值做 > 比较。
- 优先把等值条件放前面：
{"attributes.name": 1, "status": 1, "createdAt": -1}—— 这样name匹配后，能直接定位到对应子项再按 status 和时间排序 - 避免在复合索引里混用数组字段和非数组字段做范围查询，比如
{"attributes.tag": 1, "price": 1}查price > 100，很可能退化成全索引扫描 - 用
db.collection.getIndexes()确认索引是否被创建成功，特别注意字段名是否带引号或大小写错（如"Attributes.name"和"attributes.name"是两个索引）
聚合管道里提取属性数组的坑
很多人用 $unwind + $match 提取 attributes，结果一查就 OOM 或超时——因为 $unwind 会把一个含 10 个属性的文档炸成 10 个，数据量瞬间翻 N 倍。
使用场景：需要返回原始文档 + 某些属性值，或者要按属性值分组统计。但只要不是强依赖“每个属性单独一行”，就该绕开 $unwind。
- 用
$filter+$arrayElemAt在投影阶段提取目标属性，不触发文档膨胀：{$addFields: {size: {$arrayElemAt: [{$filter: {input: "$attributes", cond: {$eq: ["$$this.name", "size"]}}}, 0]}}} - 如果只是筛选，坚持用
$elemMatch配合正确索引，别为了“看起来清晰”强行进聚合 -
$reduce可以替代部分$unwind场景（比如合并所有 value 为字符串），但语法难读、调试成本高，不如应用层处理
模型设计上怎么让查询更省心
最省事的办法，是在写入时就把高频查询的属性抽成独立字段，比如 size、color、weight，哪怕它们同时还在 attributes 数组里冗余一份。
这不是“违背范式”，而是换时间换空间：MongoDB 的文档模型天然适合这种稀疏字段扩展，且现代 SSD 和内存让存储成本远低于 CPU 和锁等待。
- 写入时用应用逻辑双写：改
attributes的同时，同步更新size字段；查的时候只走size: "L"索引 - 如果属性名是动态的（比如用户自定义字段），至少把常用 TOP 20 名字固化为字段，其余保留在
attributes里供低频检索 - 注意 TTL 索引和部分索引的配合：比如只对
status: "active"的文档建attributes.name索引，减少索引体积
真正麻烦的从来不是语法怎么写，而是没想清楚“这个属性到底会被怎么查”——等数据到了千万级再回头改模型，连 mongodump 都可能卡住。
