效能
效能是一項功能。為 P99 設計，而非平均值。在最佳化之前先測量——直覺對於時間花費在何處幾乎總是錯的。
規則
- 先分析再最佳化。 猜測熱點路徑只會浪費時間。請先使用火焰圖、APM 追蹤或
EXPLAIN ANALYZE。 - 消滅 N+1 查詢。 這是服務程式碼中最大的延遲瓶頸。優先使用 JOIN、批次擷取或
IN (...)，而非逐行查詢。 - 對每個列表端點進行分頁。 無限制的結果集最終會導致 Pod 記憶體不足或使資料庫飽和。對於大型資料表，預設使用游標式分頁。
- 只為查詢條件建立索引，而非每個欄位。 每個額外的索引都會拖慢寫入速度並增加儲存空間。僅在已知查詢需要時才新增索引。
- 只投影所需的欄位。
SELECT *搭配寬 DTO 會浪費網路、記憶體和垃圾回收資源。為列表 API 回傳精簡的投影。 - 快取讀取量大、對冪等性敏感的資料。 但在加入快取之前先決定失效策略——沒有清除計劃的快取就是錯誤製造機。
- 明確設定連線和執行緒池大小。 預設值很少適用於你的工作負載。請根據下游容量而非上游來調整大小。
- 批次處理對外呼叫。 一個請求處理 100 個項目，在所有方面（延遲、CPU、資料庫連線）都勝過 100 個請求各處理一個項目。
- 避免同步的遠端呼叫鏈。 延遲會疊加。請並行分散處理，或將工作改為非同步。
- 保持酬載小巧。 壓縮回應、刪減未使用的欄位，在必要時使用二進位協定（gRPC、Protobuf）。
紅旗
- 迴圈中查詢資料庫。
- API 回傳「所有記錄」。
- 沒有 TTL 且沒有失效機制的快取。
- 在生產環境中執行緒池／連線池使用框架預設值。
- 僅顯示平均值（無 P95/P99）的延遲儀表板。