MongoDB范围查询优化核心是让范围条件尽可能靠后，确保前置等值字段高效截断数据集；若范围字段在前或无前置等值条件，索引将退化为低效遍历。
MongoDB 对 $gt、$lt、$gte、$lte、$in（含范围语义）等 Range 查询的优化，核心不在“绕开范围”，而在于让范围查询尽可能晚地发生，并确保它前面的字段能高效截断数据集——B-tree 索引天然支持范围扫描，但只有当前缀是精确匹配时，它才真正高效。
Range 查询为什么容易慢？
根本原因是：一旦索引中出现 Range 字段，其后的所有字段就无法再被该索引用于过滤或排序。比如索引 {a: 1, b: 1, c: 1}，查询 {a: 1, b: {$gt: 5}} 可以用上前两个字段；但 {b: {$gt: 5}} 就只能从 b 开始扫描，a 完全失效；更糟的是 {c: {$gt: 10}}，整个索引前缀没被利用，退化为低效范围遍历。
- 常见错误现象：
explain("executionStats")中winningPlan.stage显示IXSCAN但totalKeysExamined远大于totalDocsExamined，说明索引扫描了大量键却只命中少量文档 - 真实使用场景：分页查“最近7天订单”、按价格区间筛选商品、按时间戳拉取日志片段
- 性能影响：范围字段越靠前，索引选择性越差；若无前置等值字段，B-tree 仍需从根节点一路遍历到叶节点起始位置，I/O 次数不减反增
如何让 B-tree 索引真正加速 Range 查询？
B-tree 的优势不是“支持范围”，而是“在有序结构中快速定位起始点+连续读取”。要发挥这点，必须构造出可复用的索引前缀。
- 强制把高选择性等值字段放在 Range 字段之前：例如查“某用户最近30天订单”，索引必须是
{userId: 1, createdAt: -1}，而不是{createdAt: -1, userId: 1}—— 后者会让userId完全无法参与索引过滤 - 避免在 Range 字段后加排序：如
{status: 1, createdAt: -1, amount: 1}配合查询{status: "paid", amount: {$gt: 100}}+.sort({createdAt: -1})，此时createdAt排序无法走索引，因为amount是 Range 且在它前面 - 用
$in替代多个$or范围：MongoDB 能对$in数组中的每个值做独立索引查找并合并结果，比$or更易命中索引 - 检查是否真需要 Range：有时业务可转为离散值，比如“最近30天” → 预先计算并存储
dayBucket: "2026-04-18"字段，改用等值查询
哪些 Range 查询 MongoDB 根本没法优化？
不是所有范围都能靠索引缓解。以下情况即使建了索引，B-tree 也帮不上忙：
- 在低基数字段上建 Range 索引：如
{gender: 1}上执行{gender: {$ne: "male"}}，索引选择性接近 0.5，扫描量和全表差不多 - 使用
$not、$regex（非前缀）：这些操作符直接导致索引失效，winningPlan.stage会变成COLLSCAN - 查询条件跨多个不连续范围：如
{age: {$in: [25, 28, 32, 41]}}本身没问题，但若写成{$or: [{age: {$lt: 26}}, {age: {$gt: 40}}]}，优化器可能放弃索引 - TTL 索引不能用于普通 Range 查询：它只服务后台过期清理，
db.logs.find({createdAt: {$gt: ...}})仍需你另外建常规索引
最常被忽略的一点：B-tree 索引的“范围扫描”能力，只有在它前面的字段已经把搜索空间压缩到千级甚至百级文档时，才真正体现价值。否则，它只是把全表扫描换成了“全索引扫描”，而后者可能更慢——因为索引项比文档小，单位页能存更多键，反而导致更多页加载和更差的缓存局部性。
