北京
同一個支付數據集，你想同時看到各渠道收入、整體營收和最新到賬記錄。是跑三次聚合，還是只跑一次？
先從堅持單一職責的人說起。他們認為，每個查詢就該只返回一類結果，邏輯清晰、維護方便。按支付方式匯總，就寫一個分組聚合；求總營收，再起一條帶計數的流水線；拉最近10筆訂單，再單獨跑一趟。三條語句，互不干擾，日后單獨調優也沒顧慮。
但另一派覺得，三次請求意味著三趟全表掃描、三次網絡往返，即便加了過濾條件和索引，依然浪費資源。MongoDB從4.2版起提供的`$facet`，就是為這種場景設計的：在一個聚合階段的同一個輸入文檔集合上，并行跑多條子管道，一次返回多個結果。
`$facet`的思路更像一份打包的批量作業。你先把共同的篩選做完，比如只取已支付記錄，再把這批文檔同時塞給三組子管道，每組只負責算自己的那一部分。官方文檔把它描述成“在一個階段中對相同的輸入文檔運行多個聚合管道”，與寫多次獨立查詢相比，它節省了重復讀盤和計算。
是否真的更好，得拿真實例子拆開看。假設一個`payments`集合，文檔長這樣：
{ amount: 120, method: "card", currency: "USD", status: "paid", paidAt: "2026-05-20T10:30:00Z" }
需求很樸素：需要一個小報表，分別給出各支付方式收入、全部收入匯總以及最近幾條已付記錄。所有答案都來自同一個集合，這正是`$facet`能發揮的地方。
第一步先用`$match`過濾：{ $match: { status: "paid" } }，只保留已付款項。這一步放在`$facet`之前，能讓后續所有分支都基于干凈的輸入，避免在每個子管道里重復篩選。
然后加入`$facet`階段，內部定義三個子管道：byMethod、revenueSummary和latestPayments。它們共享同一批已付文檔，卻回答完全不同的問題。
byMethod分支的任務是按支付方式統計。它對`$method`字段分組，累加每組的金額總和，并計數各組的文檔數。這樣就不必逐條看明細，而是直接得到卡片、銀行轉賬、PayPal等渠道各自的表現。
revenueSummary分支負責整體指標。它計算整個已付集合的總收入、訂單總數以及平均每筆金額。之后用`$project`只保留需要的數字字段，剔除內部計算產生的中間值，保持輸出簡潔。
latestPayments分支關注最新數據。它先按`paidAt`倒序排列，最新的記錄排在最前面，然后只截取前幾條。原文的建議是“keeps only a few result”，實踐中通常通過`$limit`來實現，得到最近幾筆付款的完整信息。
這樣，一次數據庫請求就把三項結果一起返回，應用層直接拼裝報表、儀表板或篩選面板。少了兩次請求的開銷，流水線里的公共過濾階段也只需執行一次。
但話說回來，`$facet`也有邊界。它的所有子管道共享內存限制，復雜度過高的分支可能彼此影響性能。如果某個分支需要掃描巨量數據并做深度轉換，拆成獨立聚合反而更可控。因此，是否使用`$facet`，取決于分支之間的耦合度和資源爭用。
在VisuaLeaf這類可視化工具里，可以直觀地看到數據在`$match`之后發生分流，再一步步構建子管道，預覽每個階段的結果。這讓`$facet`的調試不再抽象——只需觀察分流點的文檔，確認分支邏輯是否符合預期。
綜合來看，當一堆查詢共享同一份過濾后的輸入，且返回結果集不大、流水線步驟相對輕量時，`$facet`是讓聚合更緊湊、網絡往返更少的好選擇。它把“多個結果”的內在依賴關系顯式化，反而讓整體意圖更清晰。但也無需用它替換所有多查詢場景，衡量好分支間的耦合與單次內存開銷，才能做出合理判斷。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
