MongoDB查询添加sort排序后长时间无返回，求数据库层面解决建议

核心问题是带sort的$or查询无法利用现有索引完成排序，触发了全量结果集的低效排序：

• 你的$or查询两个分支分别走_id单字段索引、_oid单字段索引，两个分支返回的结果是无序的，MongoDB需要把所有符合条件的结果全部拉取后再做排序操作
• 近期changes集合中符合_oid: 60b1e8dc9d0359001bb80441的文档数量大幅增长，导致需要排序的结果集远超MongoDB默认的32MB内存排序阈值，触发了磁盘外排序，所以查询耗时剧增
• 调用.explain()无响应也是因为执行计划生成阶段需要扫描大量索引/文档数据导致阻塞

• 先终止当前运行的慢查询，执行db.killOp(71111)，替换参数为你实际的opid即可
• 统计符合条件的总文档数验证假设：执行db.changes.countDocuments({_oid: ObjectId("60b1e8dc9d0359001bb80441")})，查看返回的数量是否远超预期
• 你可以临时给查询加allowDiskUse: false参数执行，如果抛出Sort operation used more than the maximum 32MB of RAM报错，即可100%确认是排序内存超限问题

方案1：新增复合索引（无需改查询/配置，长期最优） #

创建复合索引{_oid: 1, _id: -1}，该索引可以直接支撑$or的第二个分支按_id倒序返回结果，$or第一个分支查_id本身就是有序的，MongoDB可以直接归并两个有序的结果集，不需要额外排序操作，查询性能会回到毫秒级。

注意：_id的默认升序索引支持反向扫描，复合索引中_id的排序规则也可以设为1，性能差异极小。

方案2：调整数据库配置（符合你优先改配置的需求，临时过渡用） #

调大MongoDB的内存排序阈值，操作如下：

1. 临时生效（重启后恢复）：执行

db.adminCommand({setParameter: 1, internalQueryExecMaxBlockingSortBytes: 134217728})

上述命令将阈值调整到128MB，你可以根据实际结果集大小调整为更大值。
2. 永久生效：修改MongoDB配置文件mongod.conf，添加如下配置后重启服务：

setParameter:
  internalQueryExecMaxBlockingSortBytes: 134217728

注意：调大排序内存阈值会增加数据库内存占用，高并发场景下可能引发OOM，仅作为临时过渡方案，长期还是建议创建对应复合索引。

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