MySQL索引一定遵循最左前缀匹配吗？

面试记录 2026-10-13

题目：MySQL索引一定遵循最左前缀匹配吗？

难度：medium

标签：db/mysql/index, mysql/index, difficulty/medium

评分：⭐⭐⭐⭐☆（4/5）

我的回答

这个前缀匹配是 MySQL 基础的索引中使用的基础规则，但并不是一定遵守，因为它还有包括全文索引、位图索引，还有其他的索引方式。

比如全文索引，它创建的索引就是对于索引字段进行分词，然后比对，和最左前缀没什么关系。

最左前缀只是指包括联合索引和普通的索引中使用的索引规则。其实主要是联合索引，普通索引直接比对字段了，和最左前缀没什么关系。然后 Like 的时候使用的也类似于最左前缀，因为它比对是从左往右。如果是中间或者是右侧区域 Like，在左侧 Like 的时候，使用模糊匹配，它是不能走索引的，这也是最左前缀的一个体现。

全文索引就不是这样了

点评

优点：

• 抓住了"不一定"这个关键：能想到不同索引类型（全文索引）绕开最左前缀
• 举了 LIKE 反例：LIKE %xx 走不了索引、LIKE xx% 可以，说明理解了 B+ 树有序性
• 区分了单列索引和联合索引：意识到单列索引其实没有"最左"概念
• 提到了全文索引的分词机制：知道 FULLTEXT 是倒排索引，与 B+ 树规则无关

不足：

• 遗漏了 MySQL 8.0 的 Skip Scan 跳跃扫描：这是"绕开最左前缀"最典型的官方机制——低基数首列在满足一定条件下可以跳过扫描
• 遗漏了 Index Condition Pushdown (ICP)：虽然不是绕开最左前缀，但能把索引上未使用的列条件下推到存储引擎层，让"看起来用不上索引"的列也能参与过滤
• 遗漏了 Index Merge（索引合并）：OR 条件可能走多个单列索引再合并，绕过单个联合索引的最左前缀
• 遗漏了 Functional Index（MySQL 8.0）：函数表达式也能建索引，如 INDEX((lower(name)))，绕过"函数导致索引失效"
• 未提优化器成本模型：即使满足最左前缀，代价过高优化器也会放弃（如小表倾向全表扫描）
• "位图索引"用词不准：MySQL 没有位图索引，可能是想指 Memory 引擎的 Hash 索引或者 InnoDB 的 Adaptive Hash Index
• "普通索引直接比对字段"表述模糊：单列索引本身就是 B+ 树，比较是左到右的字节比较，"最左前缀"这个概念对单列索引不适用，但"从左往右匹配"本质仍成立

补充：

• 绕开最左前缀的 5 种机制：

1. Skip Scan（8.0）：低基数首列跳跃扫描，Extra=Using index condition
2. Index Merge：OR 条件多索引合并，Extra=Using union(...)
3. ICP：索引条件下推，Extra=Using index condition
4. Functional Index（8.0）：表达式建索引
5. 优化器回退：满足最左前缀但代价过高也会选全表

• 全文索引本质：InnoDB FULLTEXT 是倒排索引，需要 WITH PARSER ngram 支持中文
• Hash 索引：InnoDB Adaptive Hash Index 是自动建立的，业务无法手动控制；Memory 引擎可以显式建 Hash
• 面试加分句："最左前缀本质是 B+ 树有序性的体现，B+ 树本身有序，只有基于这个有序性才能定位和范围扫描；一旦索引类型不是 B+ 树（如全文倒排、Hash），或者优化器判断 B+ 树扫描代价过高，最左前缀规则就会被打破"

完整讲解

第一部分：知识重点剖析

核心考点定位：理解最左前缀规则的底层原因（B+ 树有序性），以及 MySQL 8.0 引入的多个"绕开"机制。

知识点拆解：

1. 最左前缀规则的底层原因

• B+ 树是多级有序结构，键比较是左到右逐字段
• (a, b, c) 索引内部：先按 a 排，a 相同时按 b 排，a、b 都相同时按 c 排
• 查询必须"先固定前面的列"才能定位后面的列的有序区间
• 跳过中间列 → 后面的列在这个前缀下无序 → 无法用索引定位

1. 最左前缀规则被打破的场景（5 类）

• Skip Scan（8.0）：当首列基数很低（如性别只有 M/F），且查询条件在首列所有取值上都满足时，优化器会跳过扫描——比如 (gender, city) 索引，WHERE city = 'Beijing' 会被拆成 gender='M' AND city='Beijing' 和 gender='F' AND city='Beijing' 两次扫描合并。EXPLAIN 显示 Using index condition
• Index Merge：WHERE a=1 OR b=2 可能走 (a) 和 (b) 两个索引再 UNION，EXPLAIN 显示 Using union(idx_a, idx_b)
• Functional Index（8.0）：INDEX((lower(name))) 让 WHERE lower(name)='x' 也能走索引
• 全文索引 / Hash 索引：完全不同的索引结构，无最左前缀概念
• 优化器放弃：即使满足最左前缀，代价过高（如匹配行数占比 > 30%）会选全表扫描

1. LIKE 与最左前缀的关系

• LIKE 'xx%'：前缀确定，走 B+ 树范围扫描
• LIKE '%xx' / LIKE '%xx%'：前缀不确定，无法利用 B+ 树有序性 → 全表扫描
• LIKE 'x_x%'：中间通配符会中断，但仍比 %xx 高效（有前缀 x）

1. ICP（Index Condition Pushdown）—— MySQL 5.6+

• 场景：(a, b, c) 索引，WHERE a=1 AND c=3（c 不是最左前缀）
• 无 ICP：先按 a=1 定位，回表读所有行，再在 Server 层过滤 c=3
• 有 ICP：c=3 条件下推到存储引擎层，在索引层过滤，减少回表
• 注意：ICP 不是绕过最左前缀，仍然是走 a=1 的索引，只是加速过滤

1. 优化器成本模型（Cost-based Optimizer）

• MySQL 是成本模型，不是规则模型
• 即使满足最左前缀，如果估算扫描行数 > 全表 30%，可能放弃索引走全表
• EXPLAIN 里看 key=None + type=ALL 就是优化器放弃索引
• FORCE INDEX / IGNORE INDEX 可以强制干预，但线上慎用（索引被删直接生产报错）

1. Hash 索引的特殊性

• InnoDB Adaptive Hash Index：InnoDB 自动维护，业务无法控制开关，只读热数据的哈希映射
• Memory 引擎：显式支持 Hash，但只支持 = 和 IN 精确匹配
• 都不涉及最左前缀规则

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否说清"最左前缀是 B+ 树有序性的必然结果"
• 广度：能否覆盖 8.0 新增的 Skip Scan、Functional Index
• 应用：能否根据 EXPLAIN 判断"为什么这里没用上索引"

延伸递进面试题：

1. Skip Scan 跳跃扫描在什么条件下生效？如何验证？

• 解答要点：首列基数低、查询在首列所有取值上都能匹配、EXPLAIN 显示 Using index condition。验证：EXPLAIN FORMAT=JSON 看 plan_info 里的 skip_scan 字段

1. (a, b, c) 索引，WHERE a=1 AND c=3 会不会因为 c 不满足最左前缀而全表扫描？

• 解答要点：不会。会走 (a) 的索引，然后 c=3 通过 ICP 下推到存储引擎层过滤，减少回表。EXPLAIN Extra 显示 Using index condition

1. 如果优化器放弃索引走全表，怎么强制走索引？有哪些风险？

• 解答要点：FORCE INDEX(idx_xxx) 或 USE INDEX。风险：索引被删或改结构后 SQL 直接生产报错；索引统计信息更新后成本变化可能不如全表快；无法动态调整。生产慎用

第三部分：面试者参考回答（口语化）

面试官您好，最左前缀不是一定遵守的，我按"底层原理 + 绕开机制"两层来讲。

底层原理：最左前缀本质是 B+ 树的有序性决定的。(a, b, c) 联合索引在 B+ 树里是先按 a 排，a 相同再按 b 排，所以必须先固定前面的列才能利用后面的列的有序区间定位。跳过中间列 → 后面的列在这个前缀下无序 → 索引用不上。这个规则只适用于 B+ 树类索引，所以索引类型本身就会打破它。

能绕开最左前缀的机制，MySQL 8.0 已经比较多了。第一是 Skip Scan 跳跃扫描，8.0 新特性，当首列基数很低（比如性别只有两个值），且查询在后列也能精确匹配时，优化器会跳过首列做一次遍历合并结果——WHERE city='Beijing' 在 (gender, city) 索引上就能跳过 gender 直接扫 city。第二是 Index Merge，WHERE a=1 OR b=2 走两个单列索引再 UNION，绕开单个联合索引。第三是 Functional Index，8.0 可以建表达式索引，INDEX((lower(name))) 让 WHERE lower(name)='x' 也能走。第四是其他索引类型，比如全文索引是倒排结构、Hash 索引是哈希定位，跟 B+ 树最左前缀规则完全无关。第五是优化器成本模型——即使满足最左前缀，如果估算扫描行数占比太高，优化器也可能直接放弃走全表。

再补充一个容易被误会的点：ICP（索引条件下推）不是绕开最左前缀，而是让"看起来用不上最左前缀"的列也在索引层过滤。(a, b, c) 索引上 WHERE a=1 AND c=3，c 虽然不在最左前缀上，但通过 ICP 下推到存储引擎层过滤，能显著减少回表次数。

至于优化器放弃索引的场景，MySQL 5.7 可以 FORCE INDEX 强制走，但生产环境慎用——索引被删或改结构 SQL 直接生产报错，而且统计信息变化后可能反而比全表慢。实际线上更推荐通过调整索引设计让优化器自动选对，而不是硬干预。

当然，最左前缀这个规则在 8.0 里被大量优化器机制"松绑"了，理解它的关键还是回到 B+ 树的有序性——只要索引结构是 B+ 树，规则本质成立；只要索引结构不是 B+ 树，或者优化器判断 B+ 树扫描代价过高，规则就会被打破。