我们之前已经给 tb_user 添加了联合索引。在实际项目中，常见的痛点是：

• 查询慢却看不到索引使用——往往是因为没有遵守最左前缀法则。
• 范围查询后面的列失效——不清楚为什么某些条件仍然走全表扫描。
• SQL 编写顺序与索引顺序不匹配导致误判——以为改动条件顺序就能“修复”索引。

左前缀法则概述

说到案例演示，不同条件组合下的执行计划

A. 三个字段全部命中 → key_len = 54

EXPLAIN SELECT * FROM tb_user
WHERE profession = '软件工程' AND age = 30 AND status = 'active';

B. 删除 status 条件 → key_len = 49

EXPLAIN SELECT * FROM tb_user
WHERE profession = '软件工程' AND age = 30;

C. 仅使用 profession → key_len = 47

EXPLAIN SELECT * FROM tb_user
WHERE profession = '软件工程';

D. 删除 profession 条件 → 索引失效

EXPLAIN SELECT * FROM tb_user WHERE age = 30 AND status = 'active';EXPLAIN SELECT * FROM tb_user WHERE status = 'active';

上述两条 SQL 均未走联合索引，因为最左边的列 profession 缺失。

E. 跳过 age，仅保留 profession 与 status → key_len = 47

EXPLAIN SELECT * FROM tb_user
WHERE profession = '软件工程' AND status = 'active';

从返回的 key_len=47 可知。MySQL 跳过了中间的 age,所以后面的 status 没有参与索引。

F. 条件顺序被打乱 → 是否仍满足最左前缀？

EXPLAIN SELECT * FROM tb_user
WHERE age = 30 AND status = 'active' AND profession = '软件工程';按理说，

只要查询里出现了最左边的列。 最左前缀法则依然成立，联合索引仍会被利用。

范围查询对联合索引的影响

A. 使用> 的范围查询 → key_len=49，仅 profession 与 age 生效。status 被放弃

EXPLAIN SELECT * FROM tb_user
WHERE profession = '软件工程' AND age> 25 AND status = 'active';

B. 使用>= 的范围查询 → key_len=54，所有三列均走索引

EXPLAIN SELECT * FROM tb_user
WHERE profession = '软件工程' AND age>= 25 AND status = 'active';

实战建议：

• If possible,prefer inclusive range operators;y keep right‑hand columns in index.
• Avoid exclusive operators on middle column of a composite index unless you’re willing to sacrifice later columns.
• If business logic permits。rewrite conditions to use “>= / <=” or split query into two步骤，以便让所有关键列都能受益于索引。

常见误区速查表