MySQL B-Tree 索引 vs Hash 索引：原理、限制與選型指南

MySQL B-Tree 索引 vs Hash 索引：原理、限制與選型指南

Hash 索引因 O(1) 查找極快，但功能受限；B-Tree 索引功能全面、支援範圍查詢、排序、前綴匹配，是 MySQL 默認選擇。本文深度對比兩者差異，助你避開選型陷阱。

Hash 索引優勢：等值查找極快

• 基於哈希表，通過鍵值計算 Hash 碼直接定位數據頁，**單次 I/O 完成查找**。
• 適合 =、IN、<=> 等值過濾，性能遠超 B-Tree（需從根節點遍歷到葉節點）。
• Memory/Heap 引擎預設使用 Hash 索引；InnoDB 自適應 Hash 索引（AHI）在熱點頁自動構建 Hash 加速。

Hash 索引五大硬傷（限制）

B-Tree 索引：全能型選手

• 有序樹結構，葉節點鏈表連接，**天然支援範圍、排序、分組、最左前綴**。
• InnoDB 聚簇索引即 B+Tree，數據與主鍵同存，主鍵查詢零回表。
• 覆蓋索引、索引下推（ICP）、MRR 等優化均建立在 B-Tree 有序特性上。

引擎支援矩陣

實戰選型決策

1. InnoDB 表：無腦用 B+Tree（主鍵聚簇 + 輔助索引），信任 AHI 自動加速熱點等值查詢。
2. Memory 表：
   • 純等值點查（如緩存表、映射表）→ USING HASH 極快。
   • 需範圍、排序、前綴 → USING BTREE。
3. 組合索引場景：必須用 B-Tree，Hash 完全不支援最左前綴。
4. 低基數列（性別、狀態）：無論 Hash 還是 B-Tree 都不建議單獨建索引，優化器傾向全表掃描。

常見誤區辨析

誤區：「Hash 索引比 B-Tree 快，所以我要把所有索引改成 Hash。」
真相：Hash 僅在「高選擇性 + 純等值點查 + Memory 引擎」下完勝。InnoDB 不允許手動建 Hash，AHI 已在後台幫你做了該做的事。

總結

**B-Tree 是關係型資料庫索引的基石**，功能完備、穩定可預期；**Hash 是特定場景（Memory 表、InnoDB AHI）的加速器**，不可通用。選型原則：**默認 B-Tree，只有在 Memory 表純等值點查且基數極高時才考慮 Hash**。