如何优化多条件OR拼接的MongoDB find查询性能

原查询高CPU的核心原因 #

• 当传入的resources列表长度较大时，平铺拼接的多分支OR查询会带来两个典型性能损耗：
  • 查询解析、执行计划生成的CPU开销随OR分支数线性上升，分支数过多时MongoDB会放弃基于索引的执行计划，退化为全集合扫描
  • 每个OR分支独立携带studentId IN(...)判断，无法高效复用复合索引的匹配能力，单次查询需要完成多次分散的索引区间扫描，额外拉高CPU占用

具体优化实现 #

优化思路是减少无效OR分支、控制单查询复杂度、配合覆盖索引降低扫描成本，代码改造如下：

1. 对入参的Resource列表按assignmentId + referrerId配对分组，合并同一配对下的所有studentIds，去掉重复的OR分支
2. 将超大查询拆成小批次执行，把单查询的OR分支数控制在MongoDB高效处理的区间（一般每批50个分支以内时，MongoDB的执行计划生成效率最高，不会出现解析占比过高的问题）
3. 构造精简后的查询逻辑，逐批执行后合并结果

对应的Kotlin实现代码：

fun findSubmissions(resources: List<Resource>): Flux<Submission> {
    // 按assignmentId + referrerId分组，合并同配对下的学生集合
    val groupedCriteria = resources
        .groupBy { it.assignmentId to it.referrerId }
        .map { (pair, resourceList) ->
            val (assignmentId, referrerId) = pair
            // 合并同配对下的所有学生ID，自动去重
            val mergedStudents = resourceList.flatMap { it.studentIds }.toSet()
            Criteria.where("assignmentId").`is`(assignmentId)
                .and("referrerId").`is`(referrerId)
                .and("studentId").`in`(mergedStudents)
        }
        .toTypedArray()

    // 拆分批次，避免单查询分支过多
    val batchSize = 50
    val batches = groupedCriteria.toList().chunked(batchSize)

    // 逐批执行查询，合并返回结果
    return Flux.fromIterable(batches).concatMap { batch ->
        val query = Query.query(Criteria().orOperator(*batch.toTypedArray()))
        template.find(query, Submission::class.java)
    }
}

配套索引优化 #

为了让查询完全走索引扫描，需要在Submission集合上创建覆盖复合索引，直接把查询需要的所有字段都包含进索引结构，避免回表查询原始文档：

db.submissions.createIndex({
    assignmentId: 1,
    referrerId: 1,
    studentId: 1
})

这个索引完全匹配查询的字段匹配顺序，MongoDB可以直接从索引中定位到符合条件的文档，不需要读取磁盘上的原始文档数据，CPU和IO开销都会大幅下降。

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