前端優化：用最小代價換取最大查詢加速
資料庫調優不只在後端，**客戶端程式碼的幾行改動，往往比重建索引更立竿見影**。
策略一：編寫限制搜尋範圍的查詢
- TOP N 分頁**：`SELECT TOP 50 ...` 只回傳首頁資料，60%+ 用戶只看第一頁。歷史交易表（ERP 庫存明細）預設只顯示前 500 筆或近 30 天，用戶點「全部」再完整查詢。
- 預設 WHERE 條件**：採購單查詢預設 `WHERE Status = '未結帳'`，避免無條件全表掃描。依表單性質與用戶習慣設定（客戶主檔筆數少可不限，明細表必限）。
- 動態建構 SQL**：前端組裝參數化查詢，僅傳遞必要欄位，減少網路傳輸與伺服器解析負擔。
策略二：盡量不使用複雜存儲過程
| 存儲過程痛點 | 前端實作優勢 |
|---|
| 執行速度不如編譯語言 (C#/Java/C++) | 前端 CPU 直接運算，無網路來回 |
| 參數多、邏輯複雜時編譯/執行計畫不穩 | 前端邏輯可單元測試、重構、版控 |
| 佔用伺服器 CPU/記憶體/鎖資源，並發爭用嚴重 | 分散到各客戶端，伺服器只做資料存取 |
| 除錯困難、部署需 DBA 協助 | 開發者自主掌控發布節奏 |
- 例：金額大小寫轉換、格式化、驗證邏輯，**全在前端做**，資料庫只存數字。
- 真正需在資料庫端：集合運算、跨表聯結、交易一致性控制、安全性/稽核觸發。
策略三：減少往返、批次處理
- 多筆 INSERT/UPDATE 合併為 **Table-Valued Parameter (TVP)** 或 `BULK INSERT`/`SqlBulkCopy` 單次送入。
- 啟用 **連接池**、**非同步執行** (`BeginExecuteReader`)，避免 UI 執行緒阻塞。
- 必要時使用 **輕量級 ORM (Dapper)** 而非重型 EF，掌控生成 SQL 品質。
前端優化檢核表
- ☐ 所有清單查詢是否有 `TOP` / `WHERE` / 分頁參數？
- ☐ 預設篩選條件是否符合 80% 使用場景？
- ☐ 是否有「無條件全表掃描」的程式碼路徑？
- ☐ 業務邏輯（格式化、計算、驗證）是否下沉到前端？
- ☐ 批次寫入是否使用 TVP/Bulk API？
- ☐ 連接字串是否啟用 `Pooling=true; Max Pool Size=...`？
結語
**最好的資料庫查詢，是發生在客戶端記憶體裡的查詢（快取）**，其次是「只讀必要資料的參數化查詢」。將運算下沉前端、限制資料傳輸範圍、批次化寫入，是低成本、高回報、DBA 與開發共同受惠的優化鐵律。
