北京
在數據庫設計中，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.
