面對效能問題，許多開發者習慣憑經驗優化（如加索引、避免 LIKE '%...'、避免函數運算在比較運算符前）。雖然方向正確，但經驗不一定能解決具體問題。正確流程應為：業務理解 → 確定瓶頸點 → 針對性優化。
最簡單有效的參考指標。開啟後執行查詢，除結果集外輸出各表 I/O 統計：
SET STATISTICS IO ON;
-- 執行目標查詢
重點關注欄位：
| 欄位 | 含義 | 關注重點 |
|---|---|---|
| logical reads | 從資料緩衝區讀取頁數 | 核心指標，數值大代表記憶體存取頻繁，需檢查索引使用、篩選條件 |
| physical reads | 從磁碟讀取頁數 | 反映冷資料存取，受緩衝區影響大 |
| scan count | 索引/表掃描次數 | 高值提示可能缺乏有效索引 |
| read-ahead reads | 預讀入緩衝頁數 | 預讀效率參考 |
| lob logical/physical reads | 大值類型 (MAX) 頁讀取 | LOB 欄位存取開銷 |
當多表聯查時，會分別列出各表 I/O。邏輯讀極高的表即為優化重點：是否掃描過多列？索引是否命中？能否增加過濾條件縮小掃描範圍？
顯示剖析、編譯、執行各階段毫秒數。用法同 IO，輸出時間統計，快速定位耗時階段。
以記錄樹形式顯示各步驟：使用索引類型、估計行數、I/O 成本、CPU 成本、執行時間等。對應執行計劃節點，適合文字模式分析。
閱讀方向：從右向左、由下向上。多表聯查顯示多步驟。重點檢查：
關鍵工具提示欄位說明：
| 項目 | 說明 |
|---|---|
| Physical Operation | 物理運算子 (Hash Join, Nested Loops 等)，紅色表示優化器警告 |
| Logical Operation | 邏輯運算子 (Inner Join 等) |
| Estimated Row Size | 輸出列估計大小 (Bytes) |
| Estimated I/O Cost | I/O 活動估計成本 |
| Estimated CPU Cost | CPU 活動估計成本 |
| Estimated Operator Cost | 該操作成本佔總成本百分比 |
| Estimated Subtree Cost | 子樹累積成本 |
| Estimated Number of Rows | 輸出列估計行數 |
綜合上述四種參考資訊，通常能精準定位問題 SQL 的癥結。剩下的就是針對性改寫：補索引、改聯結順序、拆解大查詢、引導優化器選擇更優計劃等。拋磚引玉，聰明的你必能融會貫通。
