稀疏索引真正节省空间的前提是目标字段缺失率＞30%（理想＞50%），且不依赖{$exists: false}等全量覆盖查询；它适用于middle_name、error_code等可选字段，结合unique可解决“可选字段唯一性”问题，但语义灵活性不如部分索引。
稀疏索引能显著减少索引体积，但前提是字段确实“稀疏”——即大量文档缺失该字段或值为 null。盲目加 sparse: true 不仅无效，还可能让查询意外跳过本应命中的数据。
什么时候用稀疏索引才真正节省空间？
只有当目标字段在集合中缺失率 > 30%（更理想是 > 50%），且你**不依赖该字段做全量覆盖查询**时，稀疏索引才有明显收益。例如用户资料中 middle_name、preferred_pronouns 或设备日志里的 error_code（仅出错时存在）。
- 用
db.collection.aggregate([{$group: {_id: {$ne: "$field", null}, count: {$sum: 1}} }])快速估算字段缺失比例 - 如果字段存在但值为
null，稀疏索引仍会跳过它——这点和“字段不存在”效果一致 - 若字段虽稀疏但常用于
{$exists: false}查询，稀疏索引反而会让这类查询变慢（因无法利用索引快速定位“缺失”）
唯一性 + 稀疏性：解决可选字段的重复约束问题
这是稀疏索引最典型的实战场景。比如要求每个用户的 email 唯一，但允许部分用户暂未填写邮箱。直接建唯一索引会因多个 null 冲突报错：duplicate key error collection。
- 先删掉旧索引：
db.users.dropIndex({email: 1}) - 重建带稀疏性的唯一索引：
db.users.createIndex({email: 1}, {unique: true, sparse: true}) - 此时插入多条
{name: "A"}、{name: "B"}（无email字段）完全合法；而{email: "a@b.com"}和{email: "a@b.com"}仍会被拒绝 - 注意：MongoDB 不保证
null或缺失字段的插入顺序，所以不要依赖“先插谁就留谁”
稀疏索引对查询行为的隐性影响
启用 sparse: true 后，所有涉及该字段的查询都默认“忽略缺失文档”。这看似合理，但容易在聚合或分页场景埋坑。
-
db.users.find({status: "active"})不会返回status字段不存在的文档，即使业务逻辑认为“无 status 即 active” - 在
$lookup中用稀疏字段做关联键，可能导致左连接丢失右表匹配项（因左表文档未被索引，优化器可能跳过） - 复合索引中混用稀疏字段要格外小心：
{category: 1, tags: 1}设为稀疏，意味着只要任一字段缺失，整条索引记录就不存在——不是只跳过tags - 执行
explain("executionStats")时，关注nReturned和nScannedObjects差值是否异常大，可能是稀疏性导致计划偏差
替代方案：部分索引通常比稀疏索引更可控
如果你的真实需求是“只对满足某条件的文档建索引”，比如 email 非空且已验证的用户，优先用部分索引：
db.users.createIndex({email: 1}, {partialFilterExpression: {email: {$regex: ".+@.+"}}})
相比稀疏索引，部分索引支持任意布尔表达式，语义更明确，也更容易被查询优化器识别。稀疏索引本质只是 partialFilterExpression: {field: {$exists: true}} 的语法糖，但缺乏扩展性。
真正容易被忽略的是：稀疏索引一旦创建，后续修改字段存在性逻辑时，必须同步评估所有相关查询是否仍符合预期——它不像普通索引那样“默默兜底”。
