破解 Django N+1 查詢困境：使用 select_related 與 prefetch_related 實踐指南

開篇引入

數據庫查詢性能常常是 Web 應用性能瓶頸中的重中之重。Django ORM 以簡潔直觀的 API 層將 Python 代碼與數據庫打通，卻也可能因默認的惰性加載帶來 N+1 查詢問題，造成不必要的網絡往返和性能損耗。本文立足實際項目經驗，從概念解析到實戰案例，手把手教你識別、定位并解決 N+1 查詢陷阱，幫助初學者入門、資深開發者再上層樓。

寫這篇文章的初衷在于分享多年在多種業務場景中摸索出的 ORM 優化心得。你將看到典型的 N+1 查詢示例、使用 Django Debug Toolbar 進行排查的方法，以及利用 select_related 與 prefetch_related 兩大武器實現真正的預加載。希望這份指南能提升你的開發效率，讓數據庫操作不再成為性能絆腳石。

---

1 理解 N+1 查詢問題

N+1 查詢指在獲取一條主記錄之后，針對每條主記錄再發起一次子記錄查詢的模式。舉例來說，當你獲取 10 篇文章（Article）后，再為每篇文章加載作者（Author），就會產生 1 次加載列表的查詢?+?10 次加載作者的查詢，共 11 次，這就是 N+1 查詢。

這種查詢模式在記錄量較小的開發環境中可能不易察覺，但一旦數據量放大，數據庫連接與網絡延遲會急劇上升。每次額外的子查詢不僅延長請求響應時間，也給數據庫帶來更高的并發壓力