MongoDB的$or查询太慢：为每个分支创建索引实现合并

先说结论：$or 查询性能下降，根本原因在于 MongoDB 对它的执行策略相对固化——默认不会自动合并多个分支的索引结果。要触发索引合并（即 IXSCAN + OR 执行模式），必须让每个分支都满足“独立可索引”的条件，并且索引需要覆盖所有查询字段。否则，MongoDB 就会直接执行全表扫描（COLLSCAN）。例如，db.orders.find({ $or: [{ status: "paid" }, { amount: { $gt: 1000 } }] })，即使 status 和 amount 各自建有单字段索引，MongoDB 也很可能只选用其中一个索引，甚至直接进行全表扫描。

为什么 $or 查询容易变慢

根本原因是 MongoDB 默认不会为 $or 中的多个条件分别走索引然后再合并结果集，除非每个分支都满足“独立可索引”且索引能覆盖全部筛选字段。否则，它将退化为 COLLSCAN——比如 db.orders.find({ $or: [{ status: "paid" }, { amount: { $gt: 1000 } }] })，即使 status 和 amount 各有单字段索引，MongoDB 也大概率只选取其中一个索引，甚至直接做全表扫描。

如何让 $or 走索引合并（IXSCAN + OR）

真正触发索引合并需要同时满足以下三个条件，缺一不可：

• 每个 $or 分支必须是“独立谓词”：不能嵌套 $and、$not 等复杂逻辑，也不能出现 $elemMatch 这类数组操作符。
• 每个分支的字段必须有对应的前缀索引：例如分支是 { a: 1 }，就需要有 { a: 1 } 索引；分支是 { b: 2, c: 3 }，就需要有 { b: 1, c: 1 } 索引，且索引字段顺序必须一致。
• 所有分支字段的索引必须“存在且可用”：不能是正在构建中的、被后台阻塞的，或者因 TTL 过期失效的。

满足这三个条件后，通过 .explain("executionStats") 查看执行计划，你就能看到 "stage": "OR" 节点出现，其子节点包含多个 "stage": "IXSCAN"——这才是真正的索引合并。

常见踩坑点：你以为建了索引，其实未生效

以下情况很容易让你创建的索引在 $or 查询中形同虚设：

• $or 里混用了范围查询和等值查询，但索引顺序不对：例如分支是 { type: "refund", createdAt: { $gt: ISODate(...) } }，却只建了 { createdAt: 1, type: 1 }——关键在于等值字段 type 必须放在索引的最左边。
• 使用了稀疏索引（sparse: true），但文档缺失该字段：缺失字段的文档会被跳过，导致 $or 查询结果不完整。
• 集合开启了分片，但索引未在所有分片上创建：如果只在 primary 分片建立了索引，其他分片查不到，查询就会降级为广播扫描。
• 使用了 $text 索引参与 $or：MongoDB 不支持 $text 和其他索引混合在同一个 $or 中。

替代方案：比死磕 $or 更可靠

如果索引合并这条路走不通，或你不愿意在这些边界条件上花费过多时间，不妨考虑以下更稳定、更可控的方案：

• 拆成多次查询 + 应用层去重：例如分别执行 db.orders.find({ status: "paid" }) 和 db.orders.find({ amount: { $gt: 1000 } })，然后在应用层通过 Set 合并 ObjectId 进行去重。
• 改用复合索引覆盖主路径：如果你的 $or 查询中，80% 的请求实际上都集中在某个分支上（比如多数情况是查 status: "paid"），那就可以针对这个分支建立复合索引，例如 { status: 1, amount: 1 }，再使用 .hint() 强制 MongoDB 走该索引。
• 把逻辑下沉到应用层：利用 Redis 这类缓存来存储高频 $or 组合的结果集 ID，避免每次查询都直接打到 MongoDB 上。

最后要强调一点，真正考验功力的地方不在于建立索引本身，而在于确认每个 $or 分支在真实数据分布下是否具备高区分度。像 status 这种只有 "paid"、"pending"、"failed" 几个值的低基数字段，单独建索引效果非常差，即便最终走了索引合并，性能提升也十分有限。这才是优化的关键所在。