Day 114：從 N+1 查詢到批量聚合——列表頁效能優化的正確順序

上週給欄目頁加上「每篇文章摘要 + 標籤雲」之後，本地測試一切正常，上線後卻發現分類列表頁在高峰期翻到第二頁要轉兩秒。今天沒有寫新功能，專門把這個列表頁的效能問題從頭到尾捋了一遍，順便在「效能優化到底先做什麼、後做什麼」這件事上想明白了一些。

症狀定位：先量再改，不要憑感覺

第一步不是改程式碼，而是把請求時間拆開來看。在 API 入口和資料庫連接層各加了一個計時點，請求用 request_id 串聯，結論很清晰：兩千多行日誌裡，列表介面耗時約一千八百毫秒，其中資料庫側佔了一千六百毫秒——典型的資料庫瓶頸，而不是網路或模板渲染。

接著用 pg_stat_statements 按總耗時排序，二十分鐘就抓到了兇手：標籤查詢平均每個請求執行三百二十次。也就是說，列表頁回傳二十篇文章，就為每篇文章單獨發一次標籤查詢，合計近四百條 SQL，幾乎碰到排隊上限。這是教科書級的 N+1 查詢。每次往返看起來只有幾毫秒，乘上次數再乘上並發，就成了使用者感受到的兩秒。

為什麼 N+1 總在列表頁出現

ORM 與延遲載入讓這件事變得太自然了：程式碼裡寫 article.tags，框架就幫你每篇查一次。單篇詳情頁沒問題，列表頁二十篇就是二十次往返。每次往返在同城資料庫大約是三到五毫秒，看起來不大，但它們是串行的，乘上二十就是七八十毫秒；再疊加分頁和並發請求，連接池被短查詢填滿，排隊等待會進一步放大延遲。除此之外，每次查詢的解析、執行計劃生成本身也是固定開銷，批量把這部分開銷攤薄，收益往往比給單條 SQL 加索引更明顯。

修復順序：兩步走

第一步：批量 IN 查詢

先不改資料結構，只做最樸素的改寫：列表查詢拿到二十個文章 id 之後，用 WHERE article_id = ANY($1) 一次性把標籤全部取回來，在應用層依 article_id 分組組裝成 map。這一步幾乎沒有侵入性：商業程式碼仍然假定「每篇文章帶著自己的標籤」，只是取數方式變了。上線後列表介面從一千八百毫秒降到五百毫秒左右——N+1 消失了。

第二步：聚合下推到資料庫

但大部分耗時仍在 SQL 側。於是把聚合直接下推：一條 SQL 用 LEFT JOIN 加 array_agg，把二十篇文章的標籤一次性聚合成 article_id, tags[] 兩列回傳。SQL 長這樣：

SELECT a.id, array_remove(array_agg(t.name ORDER BY t.name), NULL) AS tags
FROM articles_v4 a
LEFT JOIN article_tags at ON at.article_id = a.id
LEFT JOIN tags t ON t.id = at.tag_id
WHERE a.category_id = $1 AND a.locale = $2 AND a.status = 'published'
GROUP BY a.id
ORDER BY a.published_at DESC
LIMIT 20;

一條語句取代了過去「先取列表、再逐篇取標籤」兩輪負載。資料庫真正的敵人往往是往返次數，並發連線數是放大器——這條經驗已經反覆被打臉驗證過了。首先考慮一次載入：二十篇文章的標籤共同取回，列表頁的成本不再隨頁面文章數線性增長；其次考慮 SQL 層聚合：分頁越深，把過濾、關聯、聚合都壓進同一條語句，收益越明顯。

溢出的收穫

優化越靠前，收益越便宜。列表介面全量切到批量風格後，介面耗時下降到九十毫秒。這次經驗再次強調，效能優化不要全憑經驗直接跳進索引和快取。定位、修掉最大的收益，順序遠比工具重要。

檢查清單

先用 request_id 串聯分段計時，確認瓶頸在應用、資料庫還是網路
pg_stat_statements 按總耗時排序，不猜、先量
列表介面預設用批次預載（batch loader）或 JOIN，避免 N+1
任何「每篇 × 子表」的讀取都要在列表場景單獨看執行次數
優先在同一輪查詢裡做聚合，再考慮索引，最後才考慮快取
改動後對比壓測記錄並歸檔

優化完成後，高峰期列表介面中位數耗時穩定在九十毫秒以內，慢查詢告警也沒有再觸發。這只修復了最耗時的一段，但順序對了，後面的事才有的談。