Rails Mongoid中_id $in查询慢、keysExamined与锁计数过高问题求助

问题根因 #

• 传入的case_ids数组存在业务逻辑异常：你声明传入的ID数组长度为1000，但实际查询返回36515条文档、索引扫描键数达38102，远高于预期量级，优先排查ID数组的生成逻辑，确认是否存在重复拼接、错误引入其他业务ID的问题。
• 模型默认额外过滤条件：如果你的Case模型配置了default_scope（比如软删除、状态过滤等），仅靠主键索引会导致数据库先扫描所有匹配_id的文档，再在内存中过滤附加条件，拉高扫描量和执行耗时。
• 游标批次设置不合理：Mongoid默认的游标返回批次阈值较低，大结果集无法在单次响应中全部返回，就会触发多次getMore请求拉取剩余数据。
• 索引适配性说明：你当前的查询已经命中了{_id: 1}的默认主键索引，主键索引本身没有问题。

优化方案 #

即时优化（改动最小收益最高） #

1. 校验并处理传入的ID数组：先对数组做去重、长度校验，确认传入的ID数量符合预期后再执行查询：

# 先去重再传入查询
Case.where(:_id.in => case_ids.uniq).to_a

2. 调整游标批次大小：根据单条文档体积设置合理的批次阈值，减少getMore请求次数：

# 可根据实际情况调整批次数值，尽量让单次请求拉回所有结果
Case.where(:_id.in => case_ids.uniq).batch_size(1000).to_a

3. 按需返回字段：如果不需要查询全文档，用only指定返回字段，降低结果集体积和IO开销：

Case.where(:_id.in => case_ids.uniq).only(:需要的字段1, :需要的字段2).to_a

长期优化（适配高频同类查询） #

• 如果存在固定的附加查询条件，可建立复合覆盖索引，避免回表和内存过滤：

# 示例：给_id和软删除字段deleted_at建复合索引
index({ _id: 1, deleted_at: 1 }, { background: true })

• 如果这类按固定ID子集查询的场景是高频业务需求，可以给文档新增业务分类标签字段，比如biz_tag: "xxx"，给该字段建立索引后直接用标签过滤，替代传大量ID的$in查询，性能会有量级级提升。

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