面试官高频考点拆解最左前缀的定义与匹配规则联合索引中查询条件必须从索引的最左列开始且不能跳过中间的列。索引失效的典型场景范围查询后的列、函数操作、隐式类型转换等如何破坏最左匹配。索引长度计算与选择性如何通过前缀索引平衡查询效率与存储空间。优化器如何选择索引结合执行计划说明在不同 WHERE 条件下优化器的决策逻辑。实战中的索引设计如何根据业务查询模式设计联合索引列的顺序避免回表与索引冗余。1. 标准回答最左前缀匹配原则是 MySQL 联合索引的核心规则。它规定当查询语句使用联合索引时必须从索引定义的最左侧列开始并且只能向右逐列匹配直到遇到第一个范围条件、、BETWEEN、LIKE xxx%为止。只要查询条件中包含联合索引的第一列索引就有可能被利用如果跳过了第一列索引将完全失效。这一规则的作用是保证索引的高效利用避免随机查找其特点在于“有序性”和“结构性”——索引数据按列顺序组织查询必须尊重这一排序边界。举例说明假设有一张用户表user联合索引为(a, b, c)。查询条件WHERE a1 AND b2 AND c3能够走完整的索引WHERE a1 AND c3只能用到a列c列无法利用索引WHERE b2 AND c3则完全无法使用该联合索引。2. 核心原理从数据结构角度看BTree 索引的叶节点存储了完整的键值对。当建立联合索引(a, b, c)时MySQL 会按照a列全局排序在a值相同的记录内按b列排序再在b列相同的情况下按c列排序。这意味着索引数据的整体排序是确定的只有从最左侧列开始后续列才能利用这种排序带来的区间扫描特性。当执行WHERE a1 AND b2时InnoDB 首先根据a1定位到第一个满足条件的叶节点然后沿叶子链表向右扫描直到遇到a值变为下一个键值为止。因为b在a固定后有顺序所以b2可以快速过滤但扫描过程中在碰到b不满足条件时仍需继续向右直到a列改变才停止。如果查询条件不包含a优化器无法利用索引的有序性只能全表扫描。MySQL 官方手册也指出“如果索引是一个包含多列的索引那么只有在查询条件中使用了索引的最左边列时索引才能被用来查找记录。”这与最左前缀原则完全对应。3. 应用场景3.1 日常开发高频场景列表查询加多条件筛选如电商订单表按user_idstatuscreate_time设计联合索引用户查询“我的未支付订单”即可高效命中。分页与排序联合索引(a, b)同时支持ORDER BY a,b而不产生 filesort但ORDER BY b则无法利用索引排序。关联查询的驱动表JOIN 时被驱动表的关联字段若为联合索引最左列Nested-Loop Join 会更快。3.2 企业级真实场景在某 O2O 平台的订单系统中订单表有联合索引(merchant_id, pay_status, order_time)。商户经常查询“今日已支付订单”SQL 为SELECT * FROM orders WHERE merchant_id1001 AND pay_status1 AND order_time 2026-08-06 00:00:00。因为最左列merchant_id出现在条件中索引被充分使用扫描行数降低 90% 以上。若商户忘记传入merchant_id则索引失效DBA 监控会立即触发慢查询告警。另一种场景是日志表按(log_date, log_level)建立索引定期清理WHERE log_date 2026-01-01时可以高效删除而查询WHERE log_levelERROR则不会走该索引需要建立(log_level, log_date)辅助索引。4. 使用方式Java 实战下面通过一个 Spring Boot MyBatis-Plus 的示例演示如何设计索引以及编写对应的 SQL同时解释执行流程。// 创建表及联合索引 CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, brand_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, create_time DATETIME NOT NULL, INDEX idx_cat_brand_price (category_id, brand_id, price) ) ENGINEInnoDB; // Java 实体 Data TableName(product) public class Product { private Long id; private Integer categoryId; private Integer brandId; private BigDecimal price; private Date createTime; } // Mapper 接口 Mapper public interface ProductMapper extends BaseMapperProduct { Select(SELECT * FROM product WHERE category_id #{categoryId} AND brand_id #{brandId} AND price #{minPrice} ORDER BY price) ListProduct selectByCatAndBrand( Param(categoryId) Integer categoryId, Param(brandId) Integer brandId, Param(minPrice) BigDecimal minPrice ); }执行流程解析SQL 条件category_id ? AND brand_id ? AND price ?完全命中联合索引的前两列price为范围条件因此索引会使用category_id和brand_id进行精确查找并扫描price范围内的记录。通过EXPLAIN可以看到keyidx_cat_brand_pricekey_len根据字段类型计算Extra中可能出现Using index condition表示启用索引条件下推。如果没有category_id条件索引将无法使用。注意事项联合索引的列顺序必须与 SQL 中 AND 条件的列顺序一致不是书写顺序而是从最左列开始连续使用。避免在索引列上使用函数或运算例如WHERE YEAR(create_time)2026会导致索引失效。注意隐式类型转换如brand_id为 INT但传入字符串100MySQL 会触发类型转换可能使索引失效。5. 扩展延伸5.1 技术对比最左前缀 vs. 前缀索引对比维度最左前缀匹配前缀索引Prefix Index适用对象多列联合索引单列的字符串前缀核心规则查询必须从最左列开始连续匹配仅对列的值的前 N 个字符建立索引优点覆盖多列查询减少回表节约索引空间适合长字符串局限性范围查询后列无法使用索引无法使用覆盖索引且 ORDER BY 受限5.2 优缺点与注意事项优点极大提升多条件查询性能避免全表扫描。支持部分索引覆盖减少随机 IO。缺点索引维护成本高插入、更新、删除时需要维护索引树。设计不当会导致索引浪费若大量查询只用到中间列则需额外建立索引。实际开发注意事项区分度高的列放最左如user_id通常比status区分度高应放在联合索引的第一位。避免字段过长索引字段总长度受innodb_large_prefix限制设计时需综合考量。利用覆盖索引当查询的列都在联合索引中时可避免回表进一步提升性能。6. 面试追问面试官追问“在联合索引(a, b, c)上查询条件WHERE a1 AND c3为什么只能用到a列如果我在c列上也建了单列索引MySQL 会怎么执行”回答思路先解释 BTree 的排序特性索引按(a, b, c)顺序排列a列固定后b列有序但c列只有在a和b都确定后才有序跳过了b就无法利用c的有序性。然后说明优化器的选择MySQL 优化器会根据代价评估在该场景下可能仅使用a列进行索引查找再对c列进行过滤即Using where。如果另有c列单列索引优化器会计算两种索引的查询成本可能选择单列索引(c)加回表也可能仍选择联合索引的a列取决于数据分布和统计信息。标准答案联合索引的 BTree 叶节点按照(a, b, c)的顺序物理存储。查询WHERE a1 AND c3中因为没有b条件无法保证c列在a1的分组内有序所以 MySQL 只能使用a列进行索引范围扫描c列只能作为过滤条件Using where。如果存在(c)的单列索引优化器会根据代价模型选择更优路径通常当c3选择性很高时会优先使用c索引进行索引查找并回表但会再进行a1的过滤。
