最左前缀法则是 MySQL 联合索引中最核心的生效规则。
简单来说：如果你建立了一个包含多个列的索引，就像是在通讯录里先按"姓"排、再按"名"排一样，查询时必须从索引的最左列开始，且不能跳过中间的列。
一、 核心逻辑：像"找名字"一样思考
假设创建了一个联合索引：INDEX(col1, col2, col3)。
在底层的 B+ 树中，数据的排序逻辑是：
先根据 col1 排序。
在 col1 相同的情况下，再根据 col2 排序。
在 col2 相同的情况下，再根据col3排序。
二、 三种典型的应用场景
为了方便理解，我们假设索引是 (name, age, position)。
- 全值匹配（完全生效）
如果你在WHERE子句里用到了所有索引列，顺序无所谓（MySQL 优化器会自动调整顺序），索引完全生效。
WHERE name='张三' AND age=20 AND position='Dev' ✅
- 部分匹配（部分生效）
必须从最左边开始，连续匹配。
WHERE name='张三' ✅（用到了 name 索引）
WHERE name='张三' AND age=20 ✅（用到了 name 和 age 索引）
- 违反规则（失效）
中间断档：WHERE name='张三' AND position='Dev'
结果：只有 name 用到了索引。因为跳过了 age，position 在索引树里是无序的，无法直接定位。
非最左开头：WHERE age=20 AND position='Dev'
结果：完全失效。因为没有 name，数据库根本不知道从 B+ 树的哪一个分支开始找，只能全表扫描。
三、 两个致命的"断点"
除了跳过列，还有两种情况会导致最左前缀法则的后续部分失效：
- 范围查询（后面失效）
在联合索引中，如果中间某个列使用了范围查询（>、<、BETWEEN、LIKE 'Zhang%'），那么该列之后的索引列将失效。
WHERE name='张三' AND age > 20 AND position='Dev'
效果：name 有效，age 有效，但 position 失效。
- 模糊查询（前缀通配符）
WHERE name LIKE '张%'✅（生效）
WHERE name LIKE '%张' ❌（失效，因为开头不确定，破坏了最左原则）
四、 为什么会有这个法则？
这是由 B+ 树的排序特性决定的。
在多列索引的 B+ 树中，只有左边的列相等时，右边的列才有序。
如果你直接找 age=20 的人，在整个 B+ 树里，age=20 的记录可能散落在"张三"的分支里，也可能在"李四"的分支里。
数据库无法通过一次 B+ 树的搜索直接抓取所有 age=20 的人，只能挨个分支去找，这和全表扫描没区别。
总结口诀
带头大哥不能死，中间兄弟不能断，范围之后全完蛋。