MySQL 索引選擇性深度解析：為什麼 33% 選擇性仍走索引？對比 Oracle 25% 閾值與執行計畫實測

什麼是索引選擇性？

選擇性 = 滿足條件的行數 / 總行數。值越小（越接近 0），索引越有效；值越大（接近 1），全表掃描越划算。

實測案例

測試表與資料分布

CREATE TABLE r2 (
  id INT DEFAULT NULL,
  id1 INT DEFAULT NULL,
  cname VARCHAR(32) DEFAULT NULL,
  KEY id1 (id1)
) ENGINE=MyISAM;

-- 總行數
SELECT COUNT(*) FROM r2;  -- 250,001 (V1)

-- 條件 id1=1 的行數
SELECT COUNT(*) FROM r2 WHERE id1=1;  -- 83,036 (V2)

-- 選擇性 = 83036 / 250001 = 0.3321 (33.21%)

MySQL 執行計畫

EXPLAIN SELECT COUNT(cname) FROM r2 WHERE id1=1;
+----+-------------+-------+------+---------------+------+---------+-------+--------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref   | rows   | Extra       |
+----+-------------+-------+------+---------------+------+---------+-------+--------+-------------+
|  1 | SIMPLE      | r2    | ref  | id1           | id1  | 5       | const | 81371  | Using where |
+----+-------------+-------+------+---------------+------+---------+-------+--------+-------------+

結果：MySQL 選擇走索引（type=ref），預估掃描 81,371 行（接近實際 83,036）。

對比：Oracle 25% 閾值規則

• Oracle CBO（成本優化器）經驗法則：**選擇性 > 25% → 全表掃描**
• MySQL 優化器**無固定百分比閾值**，而是基於**成本模型**綜合評估：

Cost = IO_Cost + CPU_Cost
IO_Cost ≈ 預估訪問頁數 × IO_權重
CPU_Cost ≈ 預估處理行數 × CPU_權重

若索引為**二級索引**，MySQL 還需考慮**回表成本**（每行隨機 IO 讀取聚簇索引）。

為什麼 33% 仍走索引？

1. 表較小（25 萬行），全表掃描 IO 成本不高，但索引範圍掃描 + 回表成本更低。
2. 統計資訊準確：ANALYZE TABLE 及時更新，優化器預估行數接近真實值。
3. 覆蓋索引潛力：若查詢僅需 id1, cname 且建立 KEY idx_id1_cname (id1, cname)，可避免回表，成本進一步下降。

如何引導 MySQL 選擇正確路徑？

最佳實踐建議

1. **不要迷信固定閾值**，以 EXPLAIN 實測為準。
2. **建立覆蓋索引** 將「回表成本」歸零，大幅拓寬索引適用選擇性範圍。
3. **定期 ANALYZE TABLE** 保持統計資訊新鮮。
4. **監控 Handler_read_next / Handler_read_rnd_next** 觀察實際索引 vs 全掃行為。

結語

MySQL 索引選擇性決策基於**成本模型**而非固定百分比。33% 選擇性走索引並非 Bug，而是優化器在該資料分布、表大小、統計資訊下的理性選擇。DBA 應掌握 EXPLAIN、覆蓋索引、統計維護三板斧，引導優化器做出最佳決策。