索引是数据库加速查询的核心手段，但很多人在建索引时只关注建在哪一列，却忽略了索引类型本身对性能的影响。MySQL根据存储引擎的不同，支持多种索引类型，常见的有B-Tree索引、哈希索引、全文索引和空间索引，此外还有聚簇索引与二级索引的存储层级差异。选错类型可能导致索引完全无法发挥作用，甚至比全表扫描更慢。下面从存储结构、查询行为和适用场景三个维度逐一拆解。
B-Tree索引：默认选择背后的范围查询优势
B-Tree索引是InnoDB和MyISAM存储引擎默认的索引类型，底层通常实现为B+树。与普通B树不同，B+树的所有数据记录都存放在叶子节点，内部节点只保存键值和子节点指针，叶子节点之间通过双向链表连接。这种结构带来了两个直接好处：一是树的高度更低，磁盘IO次数更少；二是叶子节点有序，天然支持范围扫描和排序。假设你在age列上建了索引，执行WHERE age BETWEEN 20 AND 30时，MySQL可以先定位到20所在的叶子节点，然后顺着链表一直读到30，不需要回溯内部节点。
B-Tree索引适合全键值、键值范围和前缀匹配查询。所谓前缀匹配，是指针对字符串列使用LIKE 'abc%'时，索引仍然有效，因为叶子节点按照字典序排列。但如果是LIKE '%abc'，索引就无法利用，因为开头字符不确定，无法从树根开始定位。下面是一个简单的建表语句，展示B-Tree索引的创建方式：
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(100),
age INT,
email VARCHAR(100),
INDEX idx_age (age),
INDEX idx_name (name)
) ENGINE=InnoDB;
EXPLAIN SELECT * FROM users WHERE age > 25 AND age < 35;
执行计划中的type列通常会显示range，说明范围查询用到了索引。B-Tree还有一个明显限制：它要求查询条件必须从索引的最左列开始。比如复合索引(last_name, first_name)，单独用first_name查询时索引不会生效，这是最左前缀原则决定的。另外，B-Tree不擅长处理大量重复值的等值查询，区分度低的列建索引收益很小。
哈希索引：等值查询的快与范围查询的空白
哈希索引的底层是哈希表，它把索引键通过哈希函数映射到不同的桶中，每个桶存放指向实际数据行的指针。哈希索引的最大优势是等值查询极快，时间复杂度接近O(1)，因为只需要计算一次哈希值就能定位到桶。但它的劣势也非常突出：哈希表本身是无序的，所以哈希索引不支持范围查询，也无法用于排序和分组。如果执行WHERE age > 25，哈希索引完全派不上用场。
在MySQL中，只有MEMORY和NDB存储引擎支持显式创建哈希索引，InnoDB没有提供用户直接创建哈希索引的语法，但它内部实现了一种自适应哈希索引（Adaptive Hash Index）。当InnoDB发现某些热点数据频繁被等值查询时，会自动在内存中为这些页面建立哈希索引，这个过程由innodb_adaptive_hash_index参数控制。下面是在MEMORY表中创建哈希索引的例子：
CREATE TABLE hash_demo (
id INT PRIMARY KEY,
name VARCHAR(50),
INDEX USING HASH (name)
) ENGINE=MEMORY;
SELECT * FROM hash_demo WHERE name = 'tom';
哈希索引还有一个容易忽略的问题：它只存储哈希值和行指针，不保存原始键值。因此当发生哈希碰撞时，存储引擎必须回到数据行进行比较，才能确认是否真正匹配。如果哈希函数设计不好或者桶数量过少，碰撞概率升高，等值查询的性能会明显下降。此外，哈希索引无法利用覆盖索引优化，因为索引中不包含完整的字段值，任何查询都需要回表。
全文索引与空间索引：专用场景的差异化解法
全文索引用于文本内容的检索，底层采用倒排索引结构。它会把文本拆分成单词或词组，记录每个词出现在哪些文档的哪些位置。当你使用LIKE '%关键词%'时，MySQL无法利用普通B-Tree索引，只能逐行扫描；而全文索引可以通过倒排列表快速定位包含指定词的记录。在MySQL 5.6之前，全文索引仅MyISAM支持，之后InnoDB也开始支持，但针对中文需要配置ngram解析器才能按词组拆分。
CREATE TABLE articles (
id INT PRIMARY KEY,
title VARCHAR(200),
body TEXT,
FULLTEXT INDEX ft_title_body (title, body)
) ENGINE=InnoDB;
SELECT * FROM articles WHERE MATCH(title, body) AGAINST('database');
全文索引有自己的查询语法，使用MATCH...AGAINST，支持自然语言模式、布尔模式和查询扩展模式。它特别适合站内搜索、文档管理这类需要快速定位文本内容的场景。但全文索引维护成本较高，写入时需要更新倒排索引，所以不适合频繁更新的字段。另外，全文索引对停用词、最小词长和分词器敏感，不同配置可能导致查询结果与预期不一致。
空间索引则是针对地理空间数据设计的，底层通常基于R-Tree结构。R-Tree把空间对象的最小边界矩形（MBR）组织成树形结构，能够快速判断两个几何对象是否相交、包含或距离接近。MySQL中的空间索引主要用于POINT、LINESTRING、POLYGON等类型，配合MBRContains、MBRWithin等函数进行区域查询。下面创建一个包含空间索引的表：
CREATE TABLE geo (
id INT PRIMARY KEY,
location POINT NOT NULL,
SPATIAL INDEX sp_location (location)
) ENGINE=InnoDB;
SELECT id FROM geo WHERE MBRContains(
ST_GeomFromText('POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'),
location
);
空间索引解决问题的思路与全文索引类似，都是把复杂的对象比较转化为索引树上的快速筛选。但空间索引目前只在MyISAM和InnoDB中有限支持，而且函数的使用必须与索引匹配，例如在WHERE子句中对列做函数转换会导致索引失效。对于普通的业务表，空间索引应用较少，主要用于LBS、地理围栏等特定领域。
聚簇索引、二级索引与覆盖索引：存储层级的本质区别
从存储层级看，InnoDB的索引还分为聚簇索引和二级索引。聚簇索引并不是一种独立的索引类型，而是指数据行本身按照主键顺序存储在B+树的叶子节点中。也就是说，InnoDB表本身就是一棵B+树，主键索引就是数据存储结构。二级索引的叶子节点则存储主键值，而不是直接指向数据行。当你通过二级索引查询时，如果查询的列不在索引中，就需要先拿到主键值，再回到聚簇索引中查找完整数据，这个过程称为回表。
CREATE TABLE orders (
id INT PRIMARY KEY,
user_id INT,
amount DECIMAL(10,2),
KEY idx_user (user_id)
) ENGINE=InnoDB;
EXPLAIN SELECT id, user_id FROM orders WHERE user_id = 100;
上面的查询只取id和user_id，而二级索引idx_user的叶子节点本身就包含user_id和主键id，所以不需要回表，执行计划中Extra列会显示Using index，这就是覆盖索引。如果改为SELECT amount，则无法从二级索引直接获得amount，必须回表。覆盖索引是优化查询的常用手段，通过把需要返回的列加入复合索引，避免回表带来的额外磁盘IO。
聚簇索引的设计也带来一些注意点：主键不宜使用过长的字符串或者随机值，因为二级索引叶子节点要存储主键值，主键越长，二级索引越大；随机主键会导致插入时页分裂频繁，影响写入性能。MyISAM则完全不同，它的数据文件和索引文件分离，主键索引和二级索引的叶子节点都存储行指针，没有聚簇概念。理解这些存储层级的区别，有助于设计出更合理的表结构和索引组合。
综合来看，B-Tree索引是绝大多数场景的默认选择，哈希索引只适合等值查询且需要显式使用MEMORY引擎，全文索引和空间索引分别解决文本检索和地理位置查询的痛点。实际使用时，不能只看索引名称，还要结合存储引擎、查询模式和返回列来判断是否需要回表、是否触发最左前缀、是否被函数或模糊查询破坏。只有把索引类型和查询特征对应起来，才能让索引真正成为性能的放大器。