💡
除了不要全加，有一個很重要的指標- 基數 ，也就是「資料的識別度」。
**❌ 低基數 (Low Cardinality) 的欄位不要加索引：**
* **例子：** `性別` (男/女)、`啟用狀態` (True/False)。
* **原因：** 假設有 100 萬人，50 萬男、50 萬女。
* 如果你查 `WHERE gender = 'Male'`，資料庫透過索引發現有一半的人都要抓出來。
* 這時候，**直接掃描全表 (Full Table Scan) 其實比跑索引更快**。因為跑索引要「先查索引、再回表抓資料」，來來回回跳躍式讀取反而慢。
**✅ 高基數 (High Cardinality) 的才適合：**
* **例子：** `身份證字號`、`Email`、`手機號碼`、`UUID`。
* **原因：** 一查就能精準定位到極少數的幾筆，這才是索引發揮威力的地方。
附件提供：索引決策檢核表 (Index Decision Checklist)
## 什麼是複合索引？
### 關於複合索引
簡單說，就是 **「一個索引結構裡面，同時存了兩個以上的欄位值」**。
假設我們有一個索引 `INDEX idx_name_age (name, age)`。 在 B+Tree 的葉子節點裡，資料是這樣排列的：
```plaintext
('Aaron', 20) -> ('Aaron', 30) -> ('Bob', 18) -> ('Bob', 25) -> ('Charlie', 40)
```
**請注意排序邏輯：**
1. 先看第一個欄位 `name`，按字母順序排。
2. **只有當** `name` 一樣的時候，才會依據第二個欄位 `age` 排序。
3. 如果 `name` 不一樣（例如 `Aaron` 和 `Bob`），後面的 `age` 順序是無關緊要的（20, 30, 18, 25... 這是亂的）。
這就是為什麼會有 **「最左前綴原則」** —— 因為跳過第一欄，第二欄就是亂序的，索引無法導航。
### 為什麼要用複合索引？ 兩個單一索引不行嗎？
這是很多初學者會感到困惑的問題，我們來看看根據上面的範例資料。
兩個單一索引會發生什麼事情：
資料庫會這樣做：
1. 先用 `INDEX(name)` 找出所有叫 Aaron 的人（假設有 1000 個）。
2. 再用 `INDEX(age)` 找出所有 20 歲的人（假設有 5000 個）。
3. 最後在記憶體中把這兩堆資料做 **交集運算 (Intersection)**，找出重疊的那幾個。
* **缺點：** 做了兩次索引掃描，還要做集合運算，效率中等。
一個複合索引會發生什麼事情：
資料庫會這樣做：
1. 直接進入 B+Tree，鎖定 `name='Aaron'` 的區塊。
2. 在這個區塊內，因為 `age` 也是排好序的，直接跳到 `age=20` 的位置。
* **一次到位**，不用做交集運算。
* * *