




复合索引必须从最左列开始查,因B+树按索引列顺序逐级排序,仅最左列有序性支持二分查找;跳过则无法定位数据块,导致全表扫描或部分失效。
因为底层是 B+ 树,数据按索引列顺序逐级排序:先排第一列,相同时再排第二列,以此类推。数据库只能靠最左列的有序性快速定位数据块;跳过它,就等于在一本按「姓氏→名字→年龄」排序的通讯录里,直接翻到「名字=John」——根本没法二分查找。
常见错误现象:EXPLAIN 显示 type=ALL 或 key=NULL,明明建了 INDEX(a,b,c),但 WHERE b = ? 或 WHERE a = ? AND c = ? 就用不上。
WHERE a = ?、WHERE a = ? AND b = ?、WHERE a = ? AND b = ? AND c = ?
WHERE a = ? AND c = ? → 仅 a 生效,c 被跳过,不走索引WHERE b = ?、WHERE c = ?、WHERE b = ? 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 列是否“全在索引里”且“能被索引访问到”。