索引都用在什么情况下？｜阿里巴巴算法面经解析

60 秒回答模板

索引通常用在查询条件、排序分组、关联查询、唯一性约束和覆盖查询这些场景。比如 WHERE 条件中高选择性的字段适合建索引，可以让数据库从全表扫描变成范围扫描或点查；ORDER BY、GROUP BY 字段如果和联合索引顺序匹配，可以减少 filesort 和临时表；JOIN 的关联字段建索引能降低嵌套循环匹配成本；唯一索引既能加速查询，又能保证业务唯一性；覆盖索引可以让查询只访问二级索引，减少回表。不过索引也有代价，写入、更新、删除时都要维护 B+Tree，索引越多维护成本越高，占用磁盘和缓存也越多。所以实际建索引要结合字段选择性、查询频率、联合索引最左前缀、是否需要排序、是否能覆盖查询，并通过 Explain 观察 type、key、rows、Extra 等信息验证是否真的命中索引。

考点 核心作用

主线 高选择性过滤

易错点 认为所有 WHERE 字段都应该建索引，忽略字段选择性…

深入解析

核心作用

索引的本质是用额外的数据结构换查询效率，MySQL InnoDB 常见索引底层是 B+Tree。它把无序数据组织成可快速定位的结构，使数据库不必逐行扫描整张表，而是通过索引路径定位到满足条件的记录。回答中要先说明索引不是独立的性能魔法，而是服务于具体查询模式：过滤、排序、连接、去重、覆盖读取。只有当索引减少的扫描和排序成本大于维护成本时，它才值得建立。

高选择性过滤

最典型的场景是 WHERE 条件中的高选择性字段，比如用户 ID、订单号、手机号、唯一业务编号等。选择性越高，命中结果占总数据量比例越低，索引越能显著减少扫描行数。相反，性别、状态位、是否删除这类低选择性字段单独建索引通常收益有限，因为命中比例太高，优化器可能认为走索引再回表还不如全表扫描。判断是否适合建索引，关键不是字段是否常出现，而是它能否有效缩小结果集。

范围查询

范围查询也是索引常见使用场景，例如时间区间、金额区间、递增 ID 区间等，B+Tree 可以从范围起点开始顺序扫描，效率通常远好于全表扫描。需要注意的是，在联合索引中一旦某一列使用范围条件，它后面的列通常无法继续用于精确定位，只可能用于索引条件下推或过滤。因此设计联合索引时，一般把等值匹配列放前面，把范围列放后面，并结合排序需求决定最终顺序。

排序和分组

当 ORDER BY 或 GROUP BY 的字段顺序与索引顺序一致，并且查询条件符合最左前缀原则时，MySQL 可以直接按索引有序性读取数据，减少额外排序和临时表开销。比如按用户维度筛选后再按创建时间倒序取最近记录，常见做法是建立用户 ID 与创建时间的联合索引。排序字段是否适合建索引，要看排序是否高频、是否有分页、是否能与过滤条件组合，而不是看到 ORDER BY 就机械加索引。

关联查询

JOIN 场景下，关联字段非常适合建索引，尤其是被驱动表上的关联列。MySQL 常见连接执行方式会用外层结果逐行去内层表匹配，如果内层关联列没有索引，就可能反复扫描大量数据，成本迅速放大。比如订单表关联用户表，订单表的 user_id 或用户表的主键索引能帮助快速匹配。实际设计时还要考虑连接顺序、过滤条件和结果集大小，通过 Explain 查看访问类型和扫描行数。

覆盖索引

覆盖索引指查询所需字段都能从索引中取得，不需要再根据二级索引记录里的主键值回到聚簇索引查完整行。它适合高频列表查询、分页查询、只读取少量列的查询，例如根据用户 ID 查询订单状态和创建时间。如果二级索引已经包含过滤列、排序列和返回列，就能减少随机 I/O 和回表成本。但覆盖索引也会增大索引体积，不能为了覆盖所有查询而无限加宽索引。

联合索引

多条件查询通常优先考虑联合索引，而不是给每个字段都建单列索引。联合索引需要遵循最左前缀原则，索引列顺序应结合等值条件、范围条件、排序分组和字段选择性综合决定。一般来说，高频等值过滤列放前面，范围列和排序列根据查询形态放在合适位置。联合索引设计得好，一个索引可以同时服务过滤、排序和覆盖；设计得差，则可能只用到一小段前缀，甚至完全无法命中。

唯一约束

索引不只用于加速查询，唯一索引还承担数据约束功能，适合手机号、邮箱、订单号、外部流水号等天然要求唯一的业务字段。相比仅在应用层检查，数据库唯一索引能在并发写入场景下提供更可靠的最终约束，避免重复数据进入表中。回答时可以强调唯一索引兼具查询性能和一致性保障，但也要注意唯一字段的更新代价和异常处理方式。

不适合场景

索引有明显维护成本，并不适合所有字段。小表数据量少，全表扫描成本本来就低，索引收益有限；低选择性字段单独建索引可能过滤不了多少数据；频繁更新的字段建索引会导致 B+Tree 维护开销增加；很少出现在查询条件、排序、分组或连接中的字段也不该建索引。最终应通过慢查询、业务访问模式和 Explain 验证，而不是凭感觉堆索引。

易错点

认为所有 WHERE 字段都应该建索引，忽略字段选择性和查询频率。
只建多个单列索引，不根据真实组合查询设计联合索引。
不了解最左前缀原则，导致联合索引列顺序设计错误。
看到 ORDER BY 就加索引，却没有匹配过滤条件和排序方向。
为了覆盖查询把索引建得过宽，造成存储和写入维护成本过高。
忽略回表成本，只关注是否命中索引而不看实际扫描行数。
给频繁更新字段建立大量索引，导致写入和更新性能明显下降。
不使用 Explain 验证执行计划，只凭经验判断索引是否生效。

面试官追问

为什么低选择性字段不适合单独建索引？

低选择性字段命中的数据比例很高，即使走索引也要访问大量索引项和大量数据行，甚至还要频繁回表。优化器可能判断这种成本高于全表扫描，所以不会使用该索引。

联合索引的最左前缀原则是什么？

联合索引按照定义列的顺序组织数据，查询条件需要从最左列开始连续匹配，才能充分利用索引。如果跳过最左列，后面的列通常无法用于定位，只能退化为扫描或过滤。

范围查询会影响联合索引后续列吗？

会。联合索引中遇到范围条件后，范围列后面的列通常不能继续用于精确缩小扫描范围，因为范围内的数据已经不是按后续条件连续定位的结构，只能部分过滤。

什么是回表，为什么要减少回表？

回表是指通过二级索引找到主键后，再到聚簇索引读取完整行。大量回表会带来随机 I/O 或缓存访问开销，覆盖索引能直接返回所需列，从而减少这部分成本。

小表需要建索引吗？

小表不一定需要额外索引，因为全表扫描的数据量很小，优化器读取整表可能更快。除非有唯一约束、外键关联或表会快速增长，否则盲目建索引收益不明显。

如何判断一个索引是否真的有效？

可以结合慢查询日志和 Explain 判断。重点看是否使用预期 key、访问类型是否从 ALL 变好、rows 是否明显降低，以及 Extra 中是否仍出现 filesort、temporary 等高成本操作。