82% 后端面试必问！MySQL 索引分类 + 实战用法，这么答稳过！

你是不是也在突击准备面试？翻了一堆资料却还是怕被问到 “MySQL 索引有哪些”？先跟你说个扎心数据：某招聘平台去年的后端面试报告显示，82% 的技术面都会问到索引相关问题，其中 “索引分类” 更是基础中的基础，答得好直接能给面试官留下 “基础扎实” 的印象，答得含糊可就危险了！

为啥索引问题在面试里这么 “高频”？说白了，这题看似考分类，实则在考察你对 MySQL 底层原理的理解和实际开发经验。毕竟在真实业务中，索引用得对不对，直接影响数据库性能 —— 同样的查询语句，加对索引可能 0.1 秒出结果，加错了说不定要等 10 秒，这在高并发场景下简直是 “致命伤”。面试官问这个问题，就是想确认你不是只会 “CRUD” 的表面玩家，而是懂优化、有实战思维的开发。

今天咱就把 MySQL 里的核心索引分类讲透，每个类型都配实际场景，面试照着说，保准让面试官点头！

按 “数据结构” 分：这是底层逻辑，必须说清

这是最基础的分类，也是面试官最想听到的核心内容，千万别只说名字，必定要带实际应用场景！

1. B + 树索引：90% 业务都在用的 “万能选手”

咱们平时说的主键索引、唯一索引、普通索引，底层都是 B + 树结构。它的优势是能快速定位数据，还支持范围查询，简直是为业务查询量身定做的。

实际应用：列如用户表user里，id设为主键（主键索引），查select * from user where id=100时，B + 树能直接定位到叶子节点的对应数据，速度极快；再列如订单表order里建了create_time的普通索引，查 “近 7 天的订单”select * from order where create_time between '2024-01-01' and '2024-01-07'，B + 树的范围查询能力就派上用场了，比全表扫描快 10 倍都不止。

2. 哈希索引：只适合 “精准匹配” 的 “专才”

哈希索引是通过哈希函数把索引键转成哈希值存储，定位数据时像查字典一样直接找哈希值，理论上查询速度是 O (1)。但它有个大短板：不支持范围查询和排序，所以用得不多。

实际应用：只有那种 “只查单个值” 的场景才适合，列如缓存表cache里存用户的临时 Token，查询时只按token字段精准查找，这时候建哈希索引能比 B + 树快一点。但日常业务里，99% 的场景都不推荐用，面试提一句它的局限性，能加分！

3. 全文索引：处理 “模糊搜索” 的 “文字专家”

如果你做过 “文章关键词搜索” 功能，肯定懂普通的like '%关键词%'有多慢 —— 全表扫描不说，还没法分词。全文索引就是解决这个问题的，它能对文本进行分词处理，快速匹配包含关键词的记录。

实际应用：列如博客系统的article表，要实现 “搜索包含‘MySQL 优化’的文章”，建title和content的全文索引，用match(title,content) against('MySQL优化')查询，比like快几十倍。但要注意，MySQL 的全文索引对中文支持一般，实际项目里可能会结合 ES，但面试里说清它的作用就行。

按 “功能用途” 分：结合业务说，显实战经验

这部分能体现你在项目里的实际用法，比单纯说数据结构更有说服力，面试官最爱听！

1. 主键索引：表的 “身份证”，必须有且唯一

每张表都该有主键索引，它不仅能唯一标识一条记录，还能让 InnoDB 引擎通过主键组织表数据（聚簇索引），查询效率拉满。

实际应用：建表时必定要指定主键，列如user表用自增id当主键，既避免了主键值过大的问题，又能让数据按插入顺序存储，查询时更高效。面试里提一句 “不提议用 UUID 当主键，由于无序会导致 B + 树频繁分裂”，绝对是加分项！

2. 唯一索引：保证数据 “不重复” 的 “监督员”

唯一索引和主键索引类似，都能保证字段值唯一，但一张表可以有多个唯一索引，而且允许字段为 NULL（主键不行）。

实际应用：列如user表的phone字段，要保证手机号不重复，就建唯一索引unique key uk_phone(phone)。这样插入重复手机号时，MySQL 会直接报错，不用我们在代码里额外判断，既省代码又保数据一致性。

3. 普通索引：业务查询的 “常规武器”

最常用的索引类型，没有唯一性限制，想优化哪个查询字段，就给哪个字段建普通索引。

实际应用：列如做 “按用户昵称查信息” 的功能，select * from user where nickname='张三'，给nickname建普通索引key idx_nickname(nickname)，查询速度能从几百毫秒降到几毫秒。但要注意别建太多，索引会拖慢插入 / 更新速度。

4. 联合索引：优化 “多条件查询” 的 “组合拳”

当查询条件包含多个字段时，单独建多个普通索引不如建一个联合索引，由于联合索引遵循 “最左前缀匹配原则”，能一次性命中多个条件。

实际应用：列如常常查 “某用户近 7 天的订单”select * from order where user_id=100 and create_time>='2024-01-01'，建联合索引key idx_user_create(user_id, create_time)比单独建user_id和create_time索引高效得多。面试里必定要提 “最左前缀原则”，列如这个索引能匹配user_id=100，但不能匹配create_time>='2024-01-01'，这是核心考点！

按 “存储方式” 分：底层原理加分项，懂的都是高手

这部分属于进阶内容，说出来能体现你对 InnoDB 的深入理解，适合想面中大厂的同学！

1. 聚簇索引：数据和索引 “绑在一起”

InnoDB 引擎的核心特性，主键索引就是聚簇索引，它的叶子节点不仅存索引值，还存整行数据。这意味着查主键时，找到索引就找到了数据，不用再回表。

实际应用：为什么查主键比查其他字段快？就是由于聚簇索引不用回表。列如select * from user where id=100，直接从聚簇索引拿数据；但select * from user where nickname='张三'，查完普通索引还要回聚簇索引拿全量数据，这就是 “回表查询”。