MySQL入门该选B+树索引还是哈希索引？覆盖索引又该怎么用？

刚接触MySQL时，理解索引的底层类型是写出高效查询的前提。InnoDB作为最常用的存储引擎，其索引实现直接影响着数据检索速度。很多人在建表时只会无脑加索引，却不清楚B+树索引、哈希索引与覆盖索引各自适合什么场景，结果导致写入变慢或查询依然全表扫描。本文将从存储结构、查找方式和实战用法三个层面，把这三种索引讲透。

B+树索引的存储结构与查找原理

MySQL的InnoDB引擎默认使用B+树作为索引结构。B+树是一种多路平衡查找树，它的非叶子节点只存储键值与子节点指针，所有真实的数据行都挂在最底层的叶子节点上，并且叶子节点之间用双向链表串联。这样的设计让树的高度通常维持在3到4层，即使表中存放上千万条记录，一次主键查询也只需要三次左右的磁盘IO。

当我们对一个字段建立B+树索引后，数据会按照该字段的大小有序排列。正因如此，B+树索引天然支持范围查询、排序和前缀匹配。例如执行WHERE age > 20 AND age < 30时，引擎可以从叶子节点链表中直接顺着读取，而不必逐行过滤。相比之下，如果没有索引，MySQL就只能做全表扫描。

下面的示例展示了如何为一个用户表创建B+树索引，以及该索引在范围查询中的使用方式：

-- 创建用户表，InnoDB默认主键就是聚簇B+树索引
CREATE TABLE user (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  age INT,
  INDEX idx_age (age)
) ENGINE=InnoDB;

-- 利用idx_age这个B+树索引做范围查找
SELECT id, name FROM user WHERE age >= 18 AND age <= 35;

需要注意的是，B+树索引遵循最左前缀原则。如果是联合索引(a, b, c)，那么只有查询条件包含a，或者a和b，或者a、b、c全都用到时才能命中索引。如果跳过a直接查b，索引就会失效。这也是很多慢查询产生的根源。

哈希索引的特点与适用局限

哈希索引是基于哈希表实现的，它会对索引列的值调用哈希函数，将结果映射到哈希桶中，桶里记录着数据行的指针。因为哈希运算直接定位，等值查询的时间复杂度接近O(1)，在只做=、IN操作时比B+树更快。Memory存储引擎就支持显式哈希索引，而InnoDB则提供了自适应的哈希索引（Adaptive Hash Index），在检测到某些页被频繁等值访问时自动构建。

但哈希索引有明显短板：它不保存数据的有序性，所以无法支持范围查询、排序以及像LIKE 'abc%'这样的前缀匹配。另外，哈希冲突存在时引擎必须遍历桶内所有指针再逐行比对，性能会退化。下面的代码演示了Memory引擎上建立哈希索引及其只能做等值匹配的限制：

-- 使用Memory引擎并建立哈希索引
CREATE TABLE session_cache (
  token VARCHAR(64),
  data TEXT,
  INDEX USING HASH (token)
) ENGINE=MEMORY;

-- 哈希索引可以极速命中
SELECT data FROM session_cache WHERE token = 'abc123';

-- 下面的范围查询无法利用哈希索引，会全表扫描
SELECT data FROM session_cache WHERE token > 'abc';

在实际业务中，除非是纯等值查找且对延迟极度敏感的内存表，否则不建议依赖哈希索引。InnoDB的B+树索引配合缓冲池，往往能在保证通用性的同时提供足够好的性能。当发现自适应哈希索引占用过多内存时，还可以通过参数innodb_adaptive_hash_index关闭它。

覆盖索引如何减少回表开销

覆盖索引并不是一种单独的索引类型，而是指查询所需要的所有列都包含在某个索引的叶子节点中，引擎只需扫描索引就能返回结果，不必再去聚簇索引里查找数据行，这个过程叫做“不回表”。比如对(name, age)建立联合索引，执行SELECT name, age FROM user WHERE name = 'Tom'时，索引本身已经覆盖了两个字段，MySQL会直接在二级索引树上读完就返回。

使用覆盖索引能显著降低IO消耗，尤其当表行很宽、单页能放的索引项比数据行多时，查询效率提升明显。我们可以通过EXPLAIN中的Extra列看到“Using index”字样来确认是否命中覆盖索引。下面是一段验证覆盖索引效果的SQL：

-- 建立联合覆盖索引
ALTER TABLE user ADD INDEX idx_name_age (name, age);

-- 该查询只需查索引，Extra显示Using index
EXPLAIN SELECT name, age FROM user WHERE name = 'Tom';

-- 若改成查*，则要回表，覆盖失效
EXPLAIN SELECT * FROM user WHERE name = 'Tom';

设计表结构时，可以适当冗余常用查询字段到联合索引中，以换取覆盖索引的收益。但要注意索引越宽，写入和更新的代价越大，也需要更多内存与磁盘空间。因此应当在读多写少、查询模式固定的核心接口上优先考虑覆盖索引，而不是对所有查询都盲目拓宽索引列。

三种索引的选型与组合建议

回到最初的建表阶段，B+树索引应是绝大多数场景的默认选择，它能兼顾等值、范围和排序。哈希索引仅在Memory表或极热点的等值查询中作为补充。覆盖索引则是一种编写查询与设计索引时的优化思路，通过合理规划联合索引顺序，让高频查询落在索引内。

举个例子，一个订单系统常按用户ID查最近订单，又按状态过滤，可以建(user_id, status, create_time)的联合B+树索引，使SELECT user_id, status, create_time类查询成为覆盖索引，同时利用B+树的有序性做时间排序。这样既没有引入哈希索引的局限，又用覆盖索引压住了回表成本。

理解这三者的关系后，面对慢查询就不必盲目加单列索引，而是从数据访问路径出发，判断是缺了B+树的有序结构、误用了哈希导致范围失效，还是可以通过覆盖索引免去回表。把索引当成访问路径的设计，而非简单的加速开关，才能稳住MySQL的性能基线。

B+tree_indexhash_indexcovering_index修改时间：2026-08-14 15:33:32