SQL 复合索引的最左前缀原则_网络技术_宿州市腾雀网络科技有限公司

发布时间 - 2026-01-24 00:00:00 点击率：次

复合索引必须从最左列开始查，因B+树按索引列顺序逐级排序，仅最左列有序性支持二分查找；跳过则无法定位数据块，导致全表扫描或部分失效。

因为底层是 B+ 树，数据按索引列顺序逐级排序：先排第一列，相同时再排第二列，以此类推。数据库只能靠最左列的有序性快速定位数据块；跳过它，就等于在一本按「姓氏→名字→年龄」排序的通讯录里，直接翻到「名字=John」——根本没法二分查找。

常见错误现象：EXPLAIN 显示 type=ALL 或 key=NULL，明明建了 INDEX(a,b,c)，但 WHERE b = ? 或 WHERE a = ? AND c = ? 就用不上。

无效。最左前缀匹配会在遇到第一个范围条件时“截断”，后续列不再参与索引查找。

比如索引是 (user_id, status, create_time)：

WHERE user_id = 123 AND status = 'pending' AND create_time > '2025-01-01' → 只用到 user_id 和 status，create_time 不进索引查找，只在结果集里过滤
想让 create_time 也走索引？得把它挪到最后，且确保前面都是等值条件
反过来把 create_time 放前面？那 WHERE create_time > ? 就连最左列都满足不了，整个索引废掉

核心逻辑不是“哪些字段常查”，而是“哪些字段能做等值筛选 + 哪些字段要排序/分组/范围过滤”。高选择性（区分度大）的等值列优先放左，范围列尽量靠右。

例如用户表常用查询：WHERE tenant_id = ? AND status = ? ORDER BY updated_at DESC LIMIT 20

错误设计：INDEX(status, tenant_id, updated_at) → tenant_id 不是最左，索引失效
合理设计：INDEX(tenant_id, status, updated_at) → tenant_id 高区分度且必查，status 等值过滤，updated_at 支持排序免
filesort
如果还有 WHERE tenant_id = ? AND updated_at > ? 场景，就把 updated_at 换到第三位，但别动前两列位置

只有查询字段全部落在复合索引中，才能触发索引覆盖（避免回表）。但前提是这些字段本身得能被索引“触达”——仍受最左前缀限制。

比如有索引 INDEX(name, age, gender)：

SELECT name, age FROM t WHERE name = 'Alice' → ✅ 覆盖，只查索引页
SELECT age, gender FROM t WHERE age = 25 → ❌ 索引根本不用，更别说覆盖
SELECT name, gender FROM t WHERE name = 'Alice' AND age > 20 → ⚠️ name 和 age 参与查找，gender 在索引里但没用于查找；不过因全字段都在索引中，仍可覆盖

容易被忽略的一点：即使满足最左前缀，如果 SELECT * 或查了索引外字段，照样回表——索引覆盖不是自动的，得看 SELECT 列是否“全在索引里”且“能被索引访问到”。