$exists 是判断字段是否存在的唯一可靠方式，只检查键是否存在而不关心值；需组合 $ne 或 $type 排除 null、空字符串等“存在但无效”情况，并为高频 $exists 查询显式创建合适索引。
用 $exists 查询字段是否存在最直接
要查“有没有这个字段”，$exists 是唯一可靠方式。它不关心字段值是什么（null、""、0 都算存在），只判断键是否在文档中。
- 查包含
email字段的文档：{ email: { $exists: true } } - 查明确不含
phone的文档：{ phone: { $exists: false } } - 注意：
{ email: { $exists: true, $ne: null } }才能排除email: null这种“存在但为空”的情况 - 如果集合没给
email字段建索引，$exists会触发全表扫描，大数据量时很慢
字段存在但值为空？得组合 $ne 或 $type
$exists: true 会把 { email: null } 也算进去，而业务上常需要“字段存在且有实际值”。这时候不能只靠 $exists。
- 排除空字符串和
null：{ email: { $exists: true, $ne: "", $ne: null } } - 更稳妥的方式是限定类型，比如只接受字符串：
{ email: { $exists: true, $type: "string" } } -
$type支持数字码（如2表示 string）或字符串名，推荐用字符串名，可读性好 - 多个条件组合时，MongoDB 无法用单一索引高效覆盖所有条件，可能退化为内存排序或临时索引
为什么 find({ email: { $ne: null } }) 不等于“字段存在”？
这是新手最常踩的坑：$ne: null 只过滤值为 null 的文档，但对根本没 email 字段的文档完全不匹配——因为查询条件里没提“字段是否存在”，MongoDB 默认跳过缺失字段的文档。
- 结果：既漏掉
{ name: "A" }（无 email 字段），也漏掉{ email: null }（字段存在但为空） - 等价于：
{ email: { $exists: true, $ne: null } }，不是你想要的“只要字段出现就行” - 如果误用这个写法做数据清洗，很可能删掉大量本该保留的无字段文档
性能关键：给高频查询字段加 $exists 索引
$exists 查询默认无法利用普通索引，必须显式创建支持它的索引，否则即使字段已建索引，查询照样慢。
- 正确建索引：
db.users.createIndex({ email: 1 })—— 这个能加速$exists - 错误认知：认为只有
{ email: 1 }索引才有效，其实{ status: 1, email: 1 }也能用于{ email: { $exists: true } }，只要email不是前导字段就可能失效 - 复合索引中，
$exists只能利用最右前缀匹配，顺序很重要 - 测试方法：用
explain("executionStats")看executionStages里是否出现IXSCAN，而不是COLLSCAN
字段是否存在的判断逻辑比表面看起来更微妙，尤其是当数据里混着 null、缺失、空字符串时，$exists 和 $ne 的组合边界容易模糊。线上环境务必用真实数据集跑一遍 explain，别只信本地小样本结果。
