MongoDB百万级文档过滤优化咨询：索引设计与性能问题

一、优先用「过滤元数据集合」缩小查询范围 #

你提到的“仅含过滤字段的小型集合”是非常适配当前场景的方案：

• 新建一个轻量集合，只存所有需要过滤的字段+原文档的_id，单条数据控制在几百字节，远小于原7kB文档
• 所有过滤查询先在这个小集合执行，拿到匹配的_id列表后，再去原集合批量获取完整文档
• 索引只需要建在这个小集合的字段上：
  • 高频组合的过滤条件建复合索引，比如{status:1, createTime:-1}（等值+范围的经典搭配）
  • 低频或单独查询的字段建单字段索引，总索引数会远低于64个限制
• 优势：小集合的索引占用内存极少，查询时索引命中率更高，内存压力比原集合小很多

二、复合索引不用全组合，按规则精简 #

不用建所有字段组合的索引，按以下逻辑设计就能覆盖大部分场景：

• 把等值/多值匹配字段（$eq/$in）放在复合索引最前面
• 后面跟单个范围查询字段（$gte/$lte），多个范围字段会导致索引失效
• 正则匹配只保留前缀匹配（^xxx）才能用到索引，非前缀正则建议提前预处理：把字段拆成关键词数组，用$in替代正则
• 示例：如果常查status:{$in:[1,2]} + createTime:{$gte:xxx} + title:{$regex:^xxx}，索引建{status:1, createTime:-1, title:1}，注意title的正则必须是前缀匹配才能触发索引

三、通配符索引的正确打开方式 #

你之前的通配符索引没被用到，大概率是因为查询条件里普通字段优先级更高，或者复合方式不对：

• 通配符索引适合不确定字段名的动态查询，别和普通字段做复合索引（MongoDB对这类组合的索引支持有限，基本不会被选中）
• 必须同时用普通字段和通配符字段时，分两步查：先用普通字段过滤出候选集，再在候选集里用通配符字段过滤
• 特殊低频查询可以用hint()强制指定通配符索引，但别作为常规方案

四、支持新增字段的低索引方案 #

如果后续要加大量过滤字段，不想堆索引，可以试试这些方法：

• 物化视图：针对常用过滤组合预计算结果，定时刷新，查询直接读视图
• 字段拼接预处理：把多维度等值字段拼接成一个索引字段，比如"status_1_type_2_level_3"，建单字段索引，查询用$eq匹配（适合固定组合的等值查询）
• 多字段文本索引：如果很多过滤字段是字符串且支持模糊匹配，建一个多字段文本索引，用$text查询替代正则，性能提升明显

五、快速排查性能问题的技巧 #

• 用explain("executionStats")分析查询计划，看是否出现stage: COLLSCAN（全表扫描），确认索引是否生效
• 耗时久的查询拆成小批量执行，避免单次占用过多资源
• 把非前缀$regex替换为全文索引或关键词数组匹配，比如把title拆成titleKeywords: ["mongodb", "index"]，用$in查询

内容的提问来源于stack exchange，提问作者Corentin