MySQL的存储引擎支持多种索引类型，其中B+树索引和哈希索引是应用最广泛的两种，两者的底层实现逻辑差异较大，适用的查询场景也有明显区别，理解它们的特性是做好索引设计的基础。
B+树索引的结构与特性
B+树索引是MySQL默认的索引类型，InnoDB和MyISAM存储引擎都支持该索引。它的底层是一棵多路平衡查找树，所有数据都存储在叶子节点，非叶子节点仅存储索引键和子节点指针，叶子节点之间通过双向链表连接。
这种结构带来了几个核心特性：
- 支持范围查询：由于叶子节点有序且相连，查询某个区间的数据时只需要遍历对应的叶子节点区间即可
- 支持排序操作：索引本身是有序的，查询时如果排序字段和索引键一致，不需要额外进行排序
- 支持最左前缀匹配：联合B+树索引可以按照索引键的最左前缀进行查询匹配
- 查询效率稳定：树的高度通常维持在2-4层，不管查询什么数据，磁盘IO次数都相对稳定
B+树索引使用示例
创建一张用户表并添加B+树索引：
-- 创建用户表，InnoDB引擎默认使用B+树作为索引结构
CREATE TABLE user_info (
id INT PRIMARY KEY AUTO_INCREMENT,
user_name VARCHAR(50) NOT NULL,
age INT NOT NULL,
register_time DATETIME NOT NULL,
INDEX idx_age (age), -- 普通B+树索引
INDEX idx_name_age (user_name, age) -- 联合B+树索引
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 范围查询，B+树索引生效
SELECT * FROM user_info WHERE age BETWEEN 18 AND 30;
-- 最左前缀匹配查询，联合索引生效
SELECT * FROM user_info WHERE user_name LIKE '张%';
哈希索引的结构与特性
哈希索引是基于哈希表实现的，它的原理是对索引键调用哈希函数，得到对应的哈希值，哈希值对应数据的存储位置。目前只有Memory存储引擎显式支持哈希索引，InnoDB有自适应哈希索引功能，但用户无法手动干预。
哈希索引的核心特性如下：
- 等值查询效率极高：理想情况下只需要一次哈希计算就能定位到数据，时间复杂度接近O(1)
- 不支持范围查询：哈希函数计算后的哈希值是无序的，无法判断区间范围
- 不支持排序：哈希值没有顺序性，无法利用索引完成排序操作
- 存在哈希冲突：不同的索引键可能计算出相同的哈希值，需要通过链表等方式解决冲突，冲突较多时查询效率会下降
- 不支持最左前缀匹配：哈希索引是对整个索引键做哈希计算，联合哈希索引无法按照前缀查询
哈希索引使用示例
使用Memory引擎创建表并添加哈希索引：
-- 创建Memory引擎的表，指定哈希索引
CREATE TABLE user_cache (
user_id INT NOT NULL,
user_token VARCHAR(100) NOT NULL,
INDEX idx_token USING HASH (user_token) -- 显式指定哈希索引
) ENGINE=Memory DEFAULT CHARSET=utf8mb4;
-- 等值查询，哈希索引生效
SELECT * FROM user_cache WHERE user_token = 'abc123xyz';
两种索引的核心区别对比
通过下表可以直观看到B+树索引和哈希索引的差异：
| 对比维度 | B+树索引 | 哈希索引 |
|---|---|---|
| 底层结构 | 多路平衡查找树 | 哈希表 |
| 等值查询效率 | 稳定，O(log n) | 极高，理想情况O(1) |
| 范围查询支持 | 支持 | 不支持 |
| 排序操作支持 | 支持 | 不支持 |
| 最左前缀匹配 | 支持 | 不支持 | >
| 哈希冲突影响 | 无 | 冲突多时效率下降 |
| 常用存储引擎支持 | InnoDB、MyISAM | Memory |
适用场景分析
B+树索引适用场景
大部分常规业务场景都适合使用B+树索引，具体包括：
- 需要范围查询的场景，比如查询某个时间段内的订单、某个年龄区间的用户
- 需要排序或者分组的查询，比如按照注册时间倒序查询用户、按照部门分组统计人数
- 联合查询需要用到最左前缀匹配的场景，比如联合索引包含姓名和年龄，需要按照姓名前缀查询
- 作为主键索引或者唯一索引，保证数据的唯一性和查询稳定性
- InnoDB表的常规索引设计，因为InnoDB默认使用B+树作为索引结构，适配性最好
哈希索引适用场景
哈希索引仅适合特定的简单场景：
- 只需要等值查询的场景，比如根据用户ID查询用户信息、根据token查询会话数据
- 临时缓存表的索引设计，比如Memory引擎的临时表，存储热点数据做快速等值查询
- 数据量不大且等值查询频率极高的场景，比如配置表的键值对查询
注意：InnoDB的自适应哈希索引是引擎自动维护的，当某个索引的等值查询频率很高时，InnoDB会自动为这个索引页构建哈希索引提升查询速度，不需要用户手动创建。
索引选型建议
在实际项目中选型时可以参考以下原则：
- 优先选择B+树索引，除非明确确认业务只有等值查询需求，再考虑哈希索引
- 如果使用的是InnoDB或者MyISAM存储引擎，只能选择B+树索引，因为这两个引擎不支持手动创建哈希索引
- 如果是Memory引擎的临时表，且只有等值查询需求，可以选择哈希索引提升查询效率
- 联合索引尽量使用B+树类型，避免后续业务扩展需要范围查询或者前缀查询时无法使用索引