文档尺寸更小的MongoDB副本集合查询变慢，原因是什么？

一、查询逻辑变化是核心诱因 #

你调整后atr_list移除了属性组合值，直接改变了查询的匹配逻辑：

• 原集合中，针对多属性组合的查询（比如同时匹配attr1和attr2）可直接命中"attr1=value1+attr2=value2"条目，借助索引快速定位文档；
• 新集合中，相同查询需改为匹配多个单个属性条目（比如{atr_list: {$all: ["attr1=value1", "attr2=value2"]}}），这种查询要求MongoDB在索引中匹配多条件并做交集计算，甚至需回表验证文档是否同时包含多个条目，计算开销远高于直接匹配单个组合值，这是响应时间飙升的主要原因。

二、与MongoDB内存存储的关联 #

文档尺寸缩小理论上能让WiredTiger缓存容纳更多数据，但查询变慢和内存存储方式无直接关联，反而可能是两个间接因素导致：

• 缓存预热不足：新集合的一周数据为新写入内容，尚未被频繁访问，部分数据/索引仍存储在磁盘上，查询时需额外磁盘IO；而旧集合数据此前已被频繁加载至缓存，对比之下新集合查询显得更慢。
• 查询计算开销抵消缓存优势：即便数据全部在缓存中，复杂的多条件匹配逻辑需要更多CPU运算，抵消了文档变小带来的缓存效率提升，最终导致响应时间变长。

三、关于删除旧集合与compact操作的建议 #

• 删除旧集合：仅能释放磁盘空间，对新集合查询性能无直接帮助——MongoDB会在缓存空间不足时自动回收旧集合的缓存资源，无需手动删除来优化新集合的内存分配。
• compact操作：主要用于整理集合磁盘碎片、释放未使用空间。若新集合为连续写入，碎片率通常较低；且compact操作会锁定集合（WiredTiger下为读锁，写操作会被阻塞），反而可能影响业务。仅当集合碎片率极高（如频繁更新删除后）才需考虑，并非解决当前查询变慢的优先方案。

四、可行优化方向 #

• 调整索引策略：若多属性组合查询为高频场景，可针对单个属性创建复合索引（如db.collection.createIndex({"attr1": 1, "attr2": 1})，前提是能将atr_list拆分为单独字段），或针对atr_list的多值匹配优化索引。
• 保留高频组合值：若高频查询依赖特定属性组合，可在atr_list中仅保留这些高频组合值，既控制文档大小，又保证查询效率。
• 分析查询计划：用explain()分析慢查询的执行计划，确认是否有索引命中、是否存在高耗时阶段，针对性优化查询语句。

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