先说结论：$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" 几个值的低基数字段，单独建索引效果非常差，即便最终走了索引合并，性能提升也十分有限。这才是优化的关键所在。
