北京
面對“從一對多關系中篩選出孩子滿足條件、再按父親屬性排序分頁”這樣的需求，許多開發者第一反應是寫個 JOIN，然后頭疼性能。而 MongoDB 文檔模型下的多鍵索引，為此提供了一種很直觀的實現路徑。
MongoDB 的多鍵索引可以把父文檔里內嵌的子文檔數組字段，和父文檔自身的字段，一并放進一個復合索引里。比如，這兩個字段的組合索引：子文檔的 child_value 和父文檔的 parent_value。這樣一來，那些先按子文檔某個值過濾、再對父文檔排序、最后取前 N 條結果的查詢，就可以完全走索引覆蓋。
這里有兩個很容易被忽略的關鍵語義。第一，這種查詢返回的是“至少有一個孩子符合條件”的父文檔集合，返回的是去重后的父親，而不是父親-孩子對。這和關系型數據庫做父子表 JOIN，或 MongoDB 聚合管道里用 $unwind 展開數組再匹配，是根本不同的邏輯——后者會每個符合條件的子女都生成一行。多鍵索引的謂詞，本質上做的是存在性測試。
第二，索引條目的數量等于父文檔中 不重復 的孩子字段值數量，而不是孩子文檔的總數。如果一個父親有兩個孩子，孩子的 child_value 都是 0.9，那么這個父親在索引中只產生一條（0.9, parent_value）的索引項。這能減少索引膨脹，但也意味著當我們以子值的精確查找去定位父記錄時，索引的組織方式對基數很敏感。
理解了這套機制，再看關系型數據庫，比如 PostgreSQL，就想把類似思路帶過去。目前沒有一模一樣的多鍵索引，但可以通過反范式化的方式來模擬：要么在“多方”子表上冗余儲存父級的排序/過濾字段，要么在“一方”父表上聚合存儲一組合格子記錄的摘要信息。同時，依賴級聯外鍵或觸發器保證數據一致性，再配合 B-tree、GIN、甚至專用的 RUM 索引，來支撐效率更高的過濾與排序分頁。
這種跨模型的思路切換，與其說是技術堆砌，不如說是在幫我們更本質地理解“一對多關系查詢”到底想要什么：不是連接，不是展開，而是一次對父實體的存在性判定和有序檢索。想透這一點，以后在設計 API 返回值、緩存結構，甚至前端列表渲染的時候，都能少踩不少坑。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
