📚 课程目录第4章联合索引

4. 联合索引：最左前缀原则的深入理解

很多开发者学索引，都卡在了“最左前缀”上。

背口诀容易，真写SQL的时候还是懵。今天我带你把这块硬骨头啃透。说白了，联合索引就是数据库里一个“多列排序”的复合结构，它的核心规则就一句话：从索引最左边的列开始匹配，不能跳过中间的列。

4.1 联合索引的物理结构

想象一下我们有一张员工表，在 (department, age, name) 上建了联合索引。数据库实际存储时，会先按 department 排序，相同部门再按 age 排序，最后按 name 排序。

这个过程就像你整理通讯录：先按省份分组，再按城市排列，最后按联系人姓氏排列。跳过中间层级，你很难快速定位。

-- 创建联合索引的例子
CREATE INDEX idx_dept_age_name
ON employees (department, age, name);

-- 理解了存储结构，你就知道为什么下面这条SQL能用到索引
SELECT * FROM employees
WHERE department = 'Engineering' AND age = 28;

-- 而下面这条，虽然用了索引列，但无法充分发挥
SELECT * FROM employees
WHERE age = 28 AND name = 'Zhang';

我来解释一下：第一条SQL从最左列 department 开始匹配，全部能用上索引。第二条跳过了 department，直接从 age 开始匹配——索引树虽然包含 age，但第一条排序规则已经失效了，只能做全索引扫描，效率大打折扣。

4.2 最左前缀原则的三大核心场景

个人习惯用一张表来总结不同查询模式下的索引表现。你想想看，下面这四种情况，哪一种能走完整索引？

查询条件	是否匹配最左前缀	索引使用效果
`WHERE department = 'Eng'`	✅ 完全匹配第一列	高效，扫描范围小
`WHERE department = 'Eng' AND age = 28`	✅ 按顺序匹配前两列	高效，索引全覆盖
`WHERE department = 'Eng' AND name = 'Zhang'`	⚠️ 跳过中间列 age	可用索引，但只用到了 department 列
`WHERE age = 28 AND name = 'Zhang'`	❌ 跳过第一列 department	大概率全表扫描

核心结论：联合索引中，只有从左边开始连续匹配的列才能走索引。跳过一列，后面的列就“断连”了。

为什么第三行只用了 department 列？因为索引在 department 相同时按 age 排序，name 在 age 分组内部才有序。跳过了 age，name 的排序对你来说就是无序的，只能一个个比对。

4.3 实战中的两个策略

我在项目中遇到过不少因为最左前缀理解不透彻导致的慢查询。有两种最常见的解决方法，分享给你：

策略一：调整查询顺序

不改变索引的前提下，调整 WHERE 条件的顺序，保证最左列出现。很多开发者不知道，MySQL 的优化器会自动调整条件顺序，但如果你用的是某些中间件或分库分表方案，这个优化可能失效。

我的建议：写 SQL 时养成好习惯，把索引最左列写在 WHERE 的第一个位置。不依赖优化器，自己靠谱。

-- 不推荐：age 被提前
SELECT * FROM employees
WHERE age = 28 AND department = 'Engineering';

-- 推荐：department 在最前面
SELECT * FROM employees
WHERE department = 'Engineering' AND age = 28;

策略二：建立冗余索引或调整索引列顺序

如果查询模式里，age 和 name 的组合查询非常频繁，但极少用 department，可以考虑两个方案：

建新索引：(age, name)，代价是增加写操作开销
调整列顺序：把 age 放到最前面，比如 (age, name, department)

我曾经踩过的坑：有一次给日志表建了 (created_at, level, user_id) 的联合索引，因为查询常用 level 和 user_id 组合。结果 created_at 放在最前面，查询完全没用到索引。后来我加了一个 (level, user_id, created_at) 的索引，查询响应时间从 3 秒降到 30 毫秒。

4.4 联合索引与排序优化

联合索引不仅能加速查询，还能减少排序开销。如果你查询排序的字段恰好是联合索引的后续列，数据库可以免去 filesort。

-- 这条查询在 (department, age, name) 索引上可以直接完成排序
SELECT * FROM employees
WHERE department = 'Engineering'
ORDER BY age, name;

但如果改成 ORDER BY name, age，排序方向不对，又得走 filesort。所以，联合索引的列顺序要同时兼顾 WHERE 和 ORDER BY 的使用模式。

4.5 本章知识体系图

下面这张图总结了联合索引的核心逻辑，包括存储结构、匹配原则和优化方向：

联合索引设计好了，能同时兼顾查询和排序。设计不好，索引建了白建。嗯，核心就是要理解那个“前缀”的概念——不是所有列都参与索引查找，只有从左边开始连续匹配的那部分才真正起作用。