联合索引是什么
先来聊一下基础：联合索引，说白了就是把多个列打包成一个索引。比如下面这个例子：
ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, status, create_time);
这条语句创建了一个索引，里面包含user_id、status、create_time三个列。
它和单列索引的区别在哪？单列索引是对一个列建索引，联合索引是对多个列的组合建索引。可以这么理解：联合索引就像一本按"user_id + status + create_time"顺序排列的字典——先按 user_id 排，相同的再按 status 排，status 也相同的再按 create_time 排。你翻字典按顺序找内容，MySQL 也这么干。
最左前缀法则
最左前缀原则，一句话概括：查询条件必须从索引的最左列开始，连续使用，索引才能生效。
听起来有点绕？我们拆开看：
- 如果索引是 (a, b, c) 三个列
- 查询条件必须从 a 开始，然后是 b，然后是 c，中间不能跳过
直接上具体场景：
| 查询条件 | 是否命中索引 | 原因 |
|---|---|---|
| WHERE a = 1 | 命中 a | 从最左列开始 |
| WHERE a = 1 AND b = 2 | 命中 a, b | 连续使用 |
| WHERE a = 1 AND b = 2 AND c = 3 | 命中全部 | 完整使用 |
| WHERE b = 2 | 不命中 | 跳过了 a |
| WHERE b = 2 AND c = 3 | 不命中 | 跳过了 a |
| WHERE a = 1 AND c = 3 | 只命中 a | 跳过了 b |
最后那个场景值得注意：WHERE a = 1 AND c = 3。MySQL 会用 a 来定位索引范围，但 c 就没法用了——因为跳过了 b，c 在索引中的位置是散乱的，无法直接定位。
从 B+ 树结构理解为什么
要真正理解最左前缀，得钻进 B+ 树内部看看。
假设有一个联合索引 (a, b, c)，数据在 B+ 树里是这样排列的：
根节点 │ ├── [a=1, b=1, c=1] ├── [a=1, b=2, c=3] ├── [a=2, b=1, c=5] ├── [a=2, b=1, c=7] └── [a=3, b=2, c=1]
注意排序规则：先按 a 排序，a 相同再按 b 排序，b 相同再按 c 排序。
这意味着什么？
- WHERE a = 1 能走索引：a 相同的数据在 B+ 树里是挨着的，直接二分查找定位。
- WHERE a = 1 AND b = 2 也能走：a 确定后，b 相同的数据也是连续的。
- WHERE b = 2 就走不了：b 的值在不同 a 之间分布得七零八落，没有全局顺序，没法用二分查找。
索引的排序规则决定了——只有从最左列开始连续匹配，才能利用 B+ 树的有序性。
打个比方：你有一本按"省份-城市-区县"排序的通讯录。找"陕西省西安市未央区"很容易，找"陕西省未央区"也行（先定位陕西省，再跳过城市直接找区县——效率会打折扣）。但如果只给你"未央区"三个字，你根本没法翻这本通讯录，因为未央区的数据分散在全国各个省份下面。
哪些情况会失效
最左前缀只是索引失效的常见原因之一，还有几个坑需要留意：
1. 范围查询右边的列失效
-- 索引 (a, b, c)-- 只命中 a，b 和 c 失效WHERE a = 1 AND b > 5 AND c = 3
b 用了范围查询（>、<、BETWEEN），c 就没法用索引了。因为 b 的范围确定后，c 的值在范围内是无序的，无法继续二分。
2. 函数操作导致失效
-- 索引 (user_id)-- 不走索引 SELECT * FROM orders WHERE YEAR(create_time) = 2025;-- 走索引 SELECT * FROM orders WHERE create_time > '2025-01-01' AND create_time < '2025-12-31';
对索引列做函数操作，MySQL 无法利用索引的有序性。改成范围查询就能走索引。
3. 隐式类型转换
-- 索引 (phone)-- 不走索引 （phone 是 varchar，传入了 int）SELECT * FROM user WHERE phone = 13800138000;-- 走索引 SELECT * FROM user WHERE phone = '13800138000';
类型不匹配时 MySQL 会做隐式转换，相当于对索引列用了函数，索引失效。
4. LIKE 左模糊
-- 索引 (name)-- 不走索引 SELECT * FROM user WHERE name LIKE '%张';-- 走索引 SELECT * FROM user WHERE name LIKE '张%';
左模糊查询无法利用 B+ 树的有序性，只能全表扫描。
5. OR 条件（部分场景）
-- 索引 (a), (b)-- 不走索引SELECT * FROM t WHERE a = 1 OR b = 2;-- 走索引 （MySQL 8.0+ 的 Index Merge）SELECT * FROM t WHERE a = 1 OR a = 2;
如果 OR 两侧的条件涉及不同索引，早期 MySQL 只能走全表扫描。MySQL 8.0 引入了 Index Merge 优化，可以同时使用多个索引再合并结果，这在某些场景下能救命。
索引设计的实操建议
理解了原理，设计索引时记住这几条：
1. 等值查询的列放前面
-- 查询: WHERE user_id = 1 AND status = 'paid' AND create_time > '2025-01-01'-- 好的索引ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, status, create_time);-- 糟糕的索引（范围查询在前，后面的列失效）ALTER TABLE orders ADD INDEX idx_time_user_status (create_time, user_id, status);
2. 区分度高的列放前面
-- status 只有几种值，区分度低-- user_id 每个用户都不同，区分度高-- 好：user_id 放前面ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);-- 糟糕：status 放前面ALTER TABLE orders ADD INDEX idx_status_user (status, user_id);
区分度公式：COUNT(DISTINCT column) / COUNT(*)。区分度越高，索引过滤能力越强。
3. 避免创建冗余索引
-- 已有索引 (a, b, c)-- 不需要再建 (a, b)，因为 (a, b, c) 的前缀已经覆盖了 (a, b)-- 但可以考虑建 (a, b)，然后删掉 (a, b, c)（如果 c 确实用不到的话）
可以用 sys.schema_redundant_indexes 视图查找冗余索引，定期清理。
小结
最左前缀原则，本质上是 B+ 树排序规则的直接推论。索引按 (a, b, c) 排序，那就只有从 a 开始连续匹配，才能利用有序性进行二分查找。跳过前面的列，后面的列在数据分布上就是无序的，索引也就失效了。
从设计角度看，最左前缀法则的核心是：索引的列顺序决定了哪些查询能受益。 这不是简单的"怎么用索引"问题，而是"怎么设计索引"的问题——把最常用的查询条件列放在前面，把区分度高的列优先排列，让索引真正发挥应有的作用。
