數一數，一個畫面背後讀了多少次

資料正確，也可能重複做了很多工作

一個 API 端點（endpoint）先讀取申請列表，再逐項查詢相關故事；加上職位條件和指引後，每一項可能觸發好幾次資料庫讀取。畫面顯示的資料雖然正確，查詢次數卻隨着列表長度一直增加。

例如 2 + 4N，意思是兩次固定查詢，再加每項四次。這是一個算例，並非目前程式的實測次數。也要分清楚伺服器讀資料庫，與手機發出網路請求：瀏覽器只發出一次請求，伺服器背後仍可能執行很多條 SQL 查詢。

合併讀取，也保留原來的選取規則

My Next Step 在申請、支援和練習相關工作中，採用了批次讀取（grouped loaders）。一種做法是先收集父項目的 ID，一次過讀取這批 ID 對應的相關紀錄，再在記憶體裏組裝結果；另一種是透過資料庫的 batch API 送出多條預備語句（prepared statements）。減少傳輸往返次數，與減少實際執行的 SQL 語句數量，是兩種不同的改善。

合併查詢時，每條相關查詢仍必須限制在正確的參與者或機構範圍（participant / tenant scoping）。參數值必須綁定；ID 清單為空時要明確處理；若 ID 較多，應按固定上限分批查詢，避免超出資料庫的參數上限。原有的排序、沒有子紀錄時的表現，以及選取哪一個修訂版本（revision），都必須保留。不能為了加快讀取，而放寬誰可以看到紀錄的範圍。

SELECT application_id, story_id
FROM selected_stories
WHERE participant_id = ?
  AND application_id IN (?, ?, ?);

先確定結果相同，再說改善了

分別用單一項目與有代表性的較長列表統計查詢次數，並比對改動前後的選取結果是否一致，包括會否誤取其他參與者的紀錄、空白關聯如何處理，以及會否出現重複資料；同時也檢查回傳大小與執行時間。一條過於龐大的查詢，未必比幾條控制好範圍的查詢更好。

我想確認的是：不必要的工作確實減少了，而正確的人仍然只看到自己獲准查閱的資料。單看一個變小的查詢數字，還未說明全部事情。

相關專案