SQL 效能調優實戰：透過用戶端統計資訊精準定位網路傳輸瓶頸

專案組回報：單表僅 69 筆資料，用戶端執行 `SELECT *` 卻耗時 2 分 23 秒，但伺服器本機僅 2 秒。經分析，該表含 `image` 型別欄位存放圖片，單表 13 MB，跨專線 (6 Mbps) 傳輸導致嚴重網路延遲。本文示範如何用 SSMS 用戶端統計資訊 量化網路傳輸耗時，並給出優化策略。

現場還原與關鍵數據

• 資料表：`Item_Test`，69 列，保留空間 13,864 KB (資料 13,800 KB)。
• 用戶端執行 `SELECT * FROM Item_Test`：總耗時 143 秒。
• 伺服器本機 (SSMS) 執行相同查詢：2 秒。

開啟用戶端統計資訊

SSMS 工具列 → 勾選 Include Client Statistics (或 Shift+Alt+S) → 再次執行查詢 → 結果面板切換至 Client Statistics 索引標籤。

關鍵指標解讀

結論： 伺服器端處理僅 ~3 秒，97% 以上時間耗在網路傳輸 13.7 MB 圖片資料。資料庫無效能問題，瓶頸在頻寬與傳輸量。

TDS 封包流程示意

優化策略

1. 只選必要欄位： 移除 `Item_Photo`，`SELECT Id, Name, Price ...` 瞬間降為毫秒級。
2. 避免資料庫存大型二進位物件： 圖片/檔案應存檔案系統或物件儲存 (S3/Blob)，資料庫僅存路徑/URL。
3. 啟用壓縮： 壓縮資料行/資料表或應用層 gzip，減少傳輸量。
4. 分頁/延遲載入： 列表頁不載入圖片，詳情頁按需載入。

延伸：ASYNC_NETWORK_IO 等待類型

若在 `sys.dm_os_wait_stats` 觀察到大量 `ASYNC_NETWORK_IO`，代表 SQL Server 等待用戶端接收資料，同樣指向網路/用戶端處理速度不足。

心法： 效能調優需全域視角——CPU、I/O、執行計畫、網路頻寬、傳輸資料量 同等重要。別讓資料庫背負非其責的「慢查詢」黑鍋。