北京
在数据库设计中，NULL常常被简单理解为“没有值”，但SQL与MongoDB对这一状态的微妙处理，却可能成为查询性能下降和结果偏差的导火索。在SQL数据库中，NULL代表的是“未知值”，而非“值不存在”。当某个属性对于特定实体根本不适用时，关系建模的正确做法是范式化：实体在相关表中完全没有对应行，而不是让某一列为NULL。然而这一清晰界限会被外连接结果打破——不匹配的一侧所有列都被呈现为NULL，包括键列，这让开发者极易将“未知值”与“原本就没有行”混为一谈。
MongoDB有着更为隐蔽的坑：一个字段可以被显式设为null，也可以完全不存在于文档中。在BSON二进制表示里，二者截然不同——前者是值为null类型的键，后者是键的彻底缺失。但由于文档模型灵活，字段可定义也可不定义，这种差别在索引中却消失了。除部分索引外，普通索引必须为所覆盖的每个文档存储一个索引键值，当文档缺少该字段时，MongoDB会用null作为占位键，与显式null完全一致。这意味着一次索引扫描无法分辨这两种状态，要区分是null还是缺失，必须拉取完整文档并执行剩余的过滤条件。因此，针对null或$exists的过滤条件，其索引扫描变得“不精确”：查询规划器先对null键进行索引扫描，再取出文档逐一验证字段到底是真正的null还是压根不存在。
以经典的 {$exists: true} 查询为例，表面上看MongoDB应该能直接利用该字段的索引。实测表明，在一个包含八条文档的集合中，四条文有真实数值、两条显式null、两条字段缺失，查询{ num: { $exists: true } }时，索引确实被使用，却仍需进行文档取回和再过滤才能得到正确结果。这种隐藏的额外开销在高并发场景下会快速放大，不少性能故障正源于开发者误以为null和缺失是“一回事”，并默认索引能精确匹配。要想避开陷阱，建议对需要区分null与缺失的字段优先考虑建立稀疏索引或部分索引，并在查询时显式使用$type等检查，从设计源头消除歧义，别让看不见的索引偏差成为系统的性能暗礁。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
