MongoDB数组字段ingredients.id创建索引后查询仍缓慢如何优化

问题根因定位 #

从你提供的explain结果可以明确：IXSCAN阶段仅耗时0毫秒就筛选出了符合条件的28条数据的物理位置，你创建的ingredients.id多键索引已经完全生效，7-8秒的耗时全部来自后续FETCH阶段拉取完整文档的环节，和索引本身的使用无关。

可落地优化方案 #

• 限制返回字段减少IO开销：600条数据量级查询耗时数秒，最大概率是单文档体积过大，尤其是steps字段如果存储了超长文本/富媒体内容，拉取28个大文档会产生极高的IO开销。如果你的查询不需要返回全量字段，使用投影操作仅返回所需字段即可大幅降低耗时，示例语句：

  db.recipes.find({"ingredients.id":"12345"}, {name:1, ingredients:1, difficulty:1, _id:0})
  

• 创建覆盖索引跳过FETCH阶段：如果查询所需的字段固定，可以将常用返回字段加入索引构建复合覆盖索引，查询时可以直接从索引中取到所有需要的数据，完全跳过耗时的FETCH阶段，耗时可直接降到毫秒级。注意数组字段必须放在索引前缀，示例创建语句：

  db.recipes.createIndex({"ingredients.id":1, name:1, difficulty:1})
  

• 排查实例与存储性能问题：600条数据的量级哪怕全表扫描也不该达到7-8秒的耗时，建议优先排查MongoDB实例所在服务器的磁盘IO是否异常、内存是否足够容纳热数据、是否有其他高占用进程抢占资源。也可以执行db.recipes.validate()查看集合碎片率，碎片率过高时执行db.runCommand({compact:"recipes"})整理存储碎片。
• 修正索引的空格异常：你当前的索引名recipes_ingredients _id和indexBounds中的ingredients .id都存在多余空格，虽然当前没有影响索引调用，但建议删除旧索引后重新创建标准无空格的索引，避免潜在的解析异常：

  // 删除旧索引
  db.recipes.dropIndex("recipes_ingredients _id")
  // 新建标准多键索引
  db.recipes.createIndex({"ingredients.id":1})
  

• 校验字段类型匹配：确认ingredients.id的存储类型和查询传入的参数类型完全一致，比如如果存储的是数字类型，查询时传入字符串"12345"会触发隐式类型转换，虽然能返回正确结果，但会增加额外的计算开销，统一类型后可进一步优化性能。

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