測試環境

• 資料表：單表 110 萬筆隨機資料，大小 102 MB。
• 工具：phpMyAdmin SQL 查詢器 (含網路延遲)。
• 對比：同一查詢在 **有索引** vs **無索引** 兩種狀態下執行時間。

測試案例與結果 (單位：秒)

測試項目	SQL 範例	有索引	無索引	結論
A. 字串精確匹配	`WHERE col = 'abc'`	0.0005	0.3439	索引極大幅加速 (687x)
B. 主鍵查詢	`WHERE id = 12345`	0.0005	0.0004	主鍵叢集索引天然高效，無索引亦快 (全掃描 110 萬仍 < 1 秒)
C. 函數運算查詢	`WHERE UPPER(col) = 'ABC'`	0.4482	0.4882	**索引失效** (SARGable 違反)，全掃描 + 函數計算，兩者接近
D. LIKE 前綴匹配	`WHERE col LIKE 'abc%'`	0.0007	0.3487	索引可用 (Range Scan)，加速 500x
E. LIKE 模糊匹配	`WHERE col LIKE '%abc%'`	0.7361	0.7339	**索引失效** (Leading Wildcard)，全掃描，索引無幫助

核心結論

1. 精確匹配 + 索引 = 極速：B-Tree 索引完美支援 `=`、`>`、`<`、`BETWEEN`、`IN`、`LIKE 'prefix%'`。
2. 函數包裹欄位 = 索引失效：`WHERE UPPER(col)=...`、`WHERE DATE(created)=...`、`WHERE col+1=...` 皆導致全表掃描。
   **對策**：改寫為 `WHERE col = UPPER('...')`、建立計算欄位/函數索引 (MySQL 8.0+ 支援函數索引)。
3. 前導萬用字元 `%xxx%` = 索引失效：B-Tree 依前綴排序，無法利用索引定位。
   **對策**：全文索引 (FULLTEXT)、外部搜尋引擎 (Elasticsearch)、或反轉欄位儲存 (`REVERSE(col)`) 配合 `LIKE 'rev%'`。
4. 主鍵查詢極快不依賴額外索引：叢集索引即資料本身。

實務索引設計原則

• **高選擇性欄位** (唯一值多) 優先建立索引。
• **組合索引遵循最左前綴原則**：`INDEX (a,b,c)` 支援 `a`、`a,b`、`a,b,c` 查詢，不支援 `b`、`b,c`、`c`。
• **避免過度索引**：每個索引增加 `INSERT/UPDATE/DELETE` 開銷與磁碟空間，單表建議 ≤ 5 個索引。
• **覆蓋索引**：`SELECT a,b FROM t WHERE c=1` → `INDEX (c,a,b)` 避免回表查詢。
• **定期維護**：`ANALYZE TABLE` 更新統計資訊、`OPTIMIZE TABLE` 整理碎片。