在数据库开发与性能优化的实践中，MySQL 索引常常是解决“慢查询”问题的关键所在——很多时候，反复调整 SQL 语句却收效甚微，最终才发现根源在于索引设计不合理或使用不当。本文将摒弃概念堆砌，从四个实用维度系统梳理索引的分类逻辑，帮助您构建清晰的知识体系。掌握这些内容后，查询优化效率将显著提升，至少能避免 90% 的常见弯路。
一、按功能特性分类（最贴近业务开发）
对开发者而言，这是日常编码中接触最频繁的分类方式，直接影响着字段索引的选取决策。
1. 主键索引（Primary Key Index）
特点：唯一且非空，每张表仅能定义一个；InnoDB 引擎默认将其作为聚簇索引使用。
作用：唯一标识表中的每一行记录，是表结构完整性的基础。
示例：
CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(50), PRIMARY KEY (id));
2. 唯一索引（Unique Index）
特点：索引值必须唯一（但允许多个 NULL），一张表可包含多个唯一索引；主要用于业务层面的唯一性约束。
适用场景：手机号、邮箱这类需要去重但又非主键的字段。
示例：
CREATE UNIQUE INDEX idx_user_phone ON user(phone);
3. 普通索引（Normal/Index）
特点：无任何约束，纯粹为了加速查询；这也是最常用的索引类型。
适用场景：经常出现在 WHERE、JOIN、ORDER BY 子句中的字段，添加普通索引通常立竿见影。
示例：
CREATE INDEX idx_user_name ON user(name);
4. 全文索引（Full-Text Index）
特点：专门配合 MATCH ... AGAINST 语法实现全文检索；只适用于 CHAR、VARCHAR、TEXT 类型。
注意：许多开发者习惯用 LIKE '%关键词%' 进行模糊匹配，但这种写法 B+Tree 索引无法生效——此时全文索引才是唯一解决方案。
示例：
CREATE FULLTEXT INDEX idx_article_content ON article(content);
5. 组合索引（Composite / 联合索引）
特点：由多个字段组合成一个索引，但必须遵循最左前缀原则。
优势：一个组合索引即可覆盖多个查询条件，减少索引数量，同时提升多条件过滤性能。
示例：
CREATE INDEX idx_user_age_name ON user(age, name);-- 可以加速 WHERE age=25 AND name='张三'-- 也可以加速 WHERE age=25（但不能加速仅 WHERE name='张三'）
二、按底层数据结构分类（决定性能本质）
索引本质上就是数据结构，不同结构适配不同的查询模式，理解这一点才能真正明白查询快慢的根本原因。
1. B+Tree 索引（默认且最主流）
引擎支持：InnoDB、MyISAM 默认均使用此索引。
优势：
- 范围查询（
>、<、BETWEEN）毫无压力 - 排序操作（
ORDER BY）也能直接利用 - 磁盘 I/O 次数少，查询性能稳定
适用场景：能够胜任 90% 以上业务查询的通用型选手。
2. Hash 索引
引擎限制：Memory 引擎原生支持；InnoDB 内部有自适应 Hash 索引，但不可手动创建。
优势：等值查询（=、IN）速度极快，时间复杂度 O(1)。
劣势：
- 范围、排序、模糊查询均不支持
- 一旦出现哈希冲突，性能会断崖式下跌
适用场景：内存表中高频的精确匹配查询。
3. 空间索引（R-Tree）
- 支持类型：
POINT、LINESTRING、POLYGON等地理空间数据。 - 引擎支持：MyISAM、InnoDB（5.7 及以上版本）。
- 用途：GIS 应用，例如“附近 5 公里内的商家”等需求。
4. 全文索引（倒排索引结构）
- 底层原理：基于分词构建的倒排索引，与搜索引擎类似。
- 注意：它与 B+Tree 中的全文索引不是同一概念，必须使用
MATCH ... AGAINST语法才能生效。
三、按物理存储方式分类（影响 I/O 效率）
1. 聚簇索引（Clustered Index）
- 特点：索引即数据——叶子节点直接存储整行数据。
- InnoDB 规则：主键索引天然作为聚簇索引；如果建表时未指定主键，InnoDB 会隐式生成一个隐藏的聚簇索引。
- 优势：通过主键查询只需一次 I/O，效率极高。
- 注意：一张表只能拥有一个聚簇索引，因为数据物理存放仅有一份。
2. 非聚簇索引（Secondary Index / 二级索引）
- 特点：叶子节点存储的是主键值（InnoDB 下）或行指针（MyISAM 下）。
- 查询过程：先通过二级索引获取主键值，再带着主键值到聚簇索引中查找完整数据——此步骤即为常说的“回表查询”。
- 优化建议：尽量设计覆盖索引，使 SELECT 所需字段全部包含在索引中，从而跳过回表，显著提升性能。
四、按字段数量分类（设计索引时的关键考量）
| 类型 | 说明 | 注意事项 |
|---|---|---|
| 单列索引 | 仅包含一个字段 | 简单直接，但容易建多造成冗余 |
| 组合索引 | 包含 2~16 个字段（InnoDB 上限为 16 列） | 必须遵循最左前缀原则；字段顺序合理，一个索引可发挥多个作用 |
最佳实践：将区分度高、查询频率高的字段置于组合索引左侧，以最大化索引复用率。
总结：如何科学建索引？
- 主键必设：优先使用自增整数主键，避免随机 UUID 导致频繁页分裂。
- 高频查询字段加普通索引：例如状态、类型、时间等常出现在 WHERE 中的字段。
- 唯一性字段用唯一索引：如手机号、订单号，既可约束唯一性又能加速查询。
- 多条件查询优先组合索引：避免为每个字段单独建索引，组合索引通常更高效。
- 警惕索引失效：函数操作、隐式类型转换、不当的
OR条件等均会导致索引失效。 - 定期分析慢查询日志：配合
EXPLAIN查看执行计划，验证索引是否被有效使用。
