SQL Server 索引結構與實戰 (二) : SQL 寫法優化、SARG 條件與 12 條實戰經驗法則

查詢優化器會自動優化，但理解 SARG 關鍵

SQL Server **查詢分析優化器** 會自動根據 WHERE 子句決定索引使用順序，**WHERE a=1 AND b>100 與 WHERE b>100 AND a=1 效能相同**。但寫法不當會導致優化器「看不懂」，失去索引優勢。

SARG (Search ARGument) 定義：可被索引加速的條件形式

欄位名 運算子 <常數/變數>
<常數/變數> 運算子 欄位名
欄位名 運算子 <常數/變數> AND 欄位名 運算子 <常數/變數> ...

**不滿足 SARG 形式 → 索引失效 → 全表掃描。**

12 條實戰經驗法則 (含實測數據對比)

1. LIKE 通配符位置決定 SARG： name LIKE '張%' ✅ SARG；name LIKE '%張' ❌ 導掃 (前置萬用字元)。
2. OR 導致全表掃描： a=1 OR b>100 ❌。改用 UNION ALL (去重用 UNION)。
3. 否定運算子/函數破壞 SARG： NOT, !=, <>, !<, !>, NOT EXISTS, NOT IN, NOT LIKE, 函數包裹欄位 (ABS(price)<5000) ❌。
   例外：WHERE price*2 > 5000 優化器可轉為 price > 2500 ✅，但**不建議依賴隱式轉換**。
4. IN 等同 OR： tid IN (2,3) ❌ 全表掃描，索引失效。
5. 盡量少用 NOT。
6. EXISTS vs IN 效能相同： 實測 pubs 庫，STATISTICS IO 邏輯讀、掃描次數**完全一致**。NOT EXISTS vs NOT IN 亦同。選可讀性較佳者。
7. CHARINDEX vs 前置 % LIKE 效能相同： 實測 7 秒、邏輯讀 7155 **完全一致**。無效能優勢。
8. UNION 通常優於 OR，但非絕對： 不同欄位 OR → UNION 大勝 (68s vs 9s)；**同欄位 OR → UNION 反而較慢** (6.4s vs 11.6s)，因 UNION 掃描索引多次 + 去重排序開銷。
9. 欄位提取遵循「需多少取多少」： 實測取 4 欄 4.6s、3 欄 1.3s、2 欄 0.08s。**每減少一欄位，速度顯著提升**。
10. COUNT(*) 不比 COUNT(欄位) 慢： 實測 COUNT(*) 1.5s、COUNT(PK) 1.48s、**COUNT(*) 最快** (優化器自動選最小欄位統計)。長字串欄位 COUNT(title) 52s 極慢。
11. ORDER BY 聚集索引鍵效能最高： 不排序/按聚集索引排序 ≈ 170ms、邏輯讀 289；按非聚集索引 (PK) 排序 4.7s、邏輯讀 4-5 萬。**聚集索引物理有序 = 零排序成本**。正序/倒序速度相當。
12. TOP 關鍵字威力： 子查詢取 10,000 列，外層 TOP 10 僅回傳 10 列 → **物理 I/O 決定回應時間**，TOP 大幅減少網路傳輸與客戶端渲染。Oracle 無 TOP 需用 ROWNUM。

軟優化之外：硬體/網路/OS 同樣關鍵

網卡、交換機、儲存子系統、CPU 核心數、記憶體頻寬，均影響最終效能。