多表 JOIN 時慎用 TRIM()：效能殺手與優化替代方案

問題場景

因歷史設計缺陷，主鍵/外鍵長度不一致 (如主表 `CHAR(20)`，從表 `CHAR(30)`)，導致短鍵值在長欄位中以空白填充。開發者為了關聯查詢，在 `WHERE` 條件雙邊套用 `TRIM()`：

-- 低效寫法：雙邊函數導致索引失效
SELECT A.Key, B.Key, C.Key
FROM TableA A, TableB B, TableC C
WHERE TRIM(A.Key) = TRIM(B.FKey) AND TRIM(A.Col) = TRIM(C.PKey);

效能災難實測

根因分析

• SARGable 原則：`WHERE` 條件列參與函數運算 (如 `TRIM(col) = ...`)，導致優化器無法使用該欄位上的索引，被迫掃描全表 (Table Scan)。
• 連接順序放大效應：雙表時掃描 4 萬行尚可；三表時，優化器可能先掃描小表 C，再用 Nested Loop 去掃描大表 B，每次都要對 B 的 4 萬行做 `TRIM` 運算，CPU 爆炸。

優化方案：單邊函數 + 索引覆蓋

核心原則：將函數運算移至「非索引鍵」或「常數/參數」側，保留驅動表索引欄位「裸露」。

-- 優化寫法：僅對「髒資料側」 (長欄位/從表) 做 TRIM
SELECT A.Key, B.Key, C.Key
FROM TableA A
INNER JOIN TableB B ON A.Key = TRIM(B.FKey)  -- A.Key 有索引，B.FKey 無索引或髒資料
INNER JOIN TableC C ON A.Col = TRIM(C.PKey); -- 同理

進階根治策略 (治本)

1. 資料清洗：一次性 `UPDATE TableB SET FKey = TRIM(FKey)`，並修正應用端寫入邏輯 (RTRIM/LTRIM)。
2. 計算欄位 + 索引 (SQL 2000+ 支援)：
   `ALTER TABLE TableB ADD CleanFKey AS RTRIM(LTRIM(FKey)) PERSISTED;`
   `CREATE INDEX IX_CleanFKey ON TableB (CleanFKey);`
   查詢直接 `ON A.Key = B.CleanFKey`，零運算開銷。
3. 統一資料類型/長度：修改欄位定義 `ALTER COLUMN` 使長度一致 (需評估影響範圍)。

最佳實踐總結

「WHERE 條件裡，索引欄位要裸奔，髒資料欄位才包函數。」
永遠檢視執行計畫：是否出現 Table Scan 或 Index Scan 而非 Index Seek？若是，檢查是否有函數、隱含轉換、或運算符導致 SARGable 失效。