部分索引通过partialFilterExpression精准索引高频查询子集（如近7天已支付订单），跳过95%冷数据，空间占用从12.5GB降至640MB，降幅95%；稀疏索引仅按字段存在性粗筛，无法区分业务价值。
当你面对一个包含上亿条文档的订单集合，其中只有最近7天的500万条记录被高频查询，而传统稀疏索引仍会为所有含status字段的文档建索引（哪怕它们是3年前已归档的“cancelled”订单），部分索引则能直接跳过这些冷数据，只索引真正参与查询的子集——这种精准裁剪才是空间节省的根本来源。
核心差异：过滤逻辑的颗粒度不同
稀疏索引的过滤能力仅限于“字段是否存在”，它像一把粗筛网：只要文档里有status字段，无论值是"paid"、"refunded"还是"archived"，全都要进索引。这导致大量低频或无效状态的文档仍占用索引空间。
部分索引的partialFilterExpression支持多维条件组合，例如{status: "paid", created_at: {$gt: ISODate("2026-08-31T00:00:00Z")}}——它只索引同时满足两个条件的文档，跳过其余95%的冗余数据。
这一步操作起来很简单，直接在createIndex中传入partialFilterExpression对象即可，但必须确保表达式中的字段类型与实际存储一致，【字符串日期如"2026-08-31"无法匹配BSON Date类型的created_at字段，会导致索引完全失效】。
空间节省的量化原理
MongoDB索引大小 ≈ 索引条目数 × 单条记录平均体积。假设单条索引记录占128字节：
全量索引：1亿文档 × 128字节 = 12.5GB
稀疏索引（80%文档含status字段）：8000万 × 128字节 = 10GB
部分索引（仅索引500万条近期已支付订单）：500万 × 128字节 = 640MB
从12.5GB到640MB，降幅达95%，而稀疏索引仅比全量少20%。关键在于：稀疏索引无法区分status字段的业务价值，部分索引却能按真实查询场景做精准截断。
验证是否真正省了空间
方法一：查索引大小
执行db.orders.stats({indexDetails: true})，找到目标索引的size字段值，对比全量索引的大小。下降幅度低于85%说明过滤条件可能过于宽松或未对齐查询。
方法二：看执行计划是否跳过冷数据
对{status: "paid", created_at: {$gt: ISODate("2026-08-31T00:00:00Z")}}执行explain("executionStats")，确认nReturned与totalDocsExamined接近且远小于集合总文档数——这意味着MongoDB确实只扫描了索引覆盖的子集。
方法三：反向验证跳过行为
执行db.orders.find({status: "cancelled"})并查看执行计划，应看到stage为COLLSCAN而非IXSCAN，证明该查询因不满足partialFilterExpression被主动排除，不会污染索引空间。
为什么不能用$or或$regex替代多条件
第一步：打开mongosh连接到目标数据库
第二步：尝试创建含$or的索引：db.orders.createIndex({user_id: 1}, {partialFilterExpression: {$or: [{status: "paid"}, {status: "refunded"}]}})
第三步：命令会直接报错Command failed with error 67 (InvalidOptions): "Partial index filter cannot contain $or"。MongoDB硬性禁止非确定性操作符，因为$or会使索引边界不可预测，无法保证B-Tree结构的有序性——这会导致范围扫描失效，彻底破坏索引价值。
第四步：改用显式$and组合：{status: {$in: ["paid", "refunded"]}}依然非法，但{status: "paid"}或{status: "refunded"}各自建独立部分索引是允许的。
