联合索引不是“多个字段拼一起”，而是按顺序建的三棵子索引树
很多人误以为
INDEX(a,b,c)就是把三个字段值连起来哈希或排序，其实 MySQL（InnoDB）用的是 B+ 树，它会**天然生成三个逻辑索引结构**：
(a)、
(a,b)、
(a,b,c)。这就像字典：先按拼音首字母分大类（a），同类里再按第二个字母细分（a,b），再细到第三个（a,b,c）。跳过首字母直接查“ba”开头的词？整本翻。 查询
WHERE a = 1→ 走
(a)子索引 查询
WHERE a = 1 AND b > 10→ 走
(a,b)（b 是范围，c 就断了） 查询
WHERE a = 1 AND b = 2 AND c = 3→ 完整走
(a,b,c)查询
WHERE b = 2或
WHERE c = 3→ **全表扫描**，B+ 树根节点没提供入口分支
为什么 WHERE a = 1 AND c = 3
只用上 a，c 却失效？
因为 B+ 树中，
a有序，
a+b有序，
a+b+c也有序；但一旦
a固定，
c在物理存储上仍是无序的——它依赖
b的值来组织。相当于：你锁定“北京”后，朝阳区的人按出生年份排好了，但如果你跳过“朝阳”直接找“1990年出生”，就得把北京所有区（海淀、西城、朝阳……）的 1990 年数据全扫一遍。
WHERE a = 1 AND c = 3：优化器只用
a定位数据块，
c条件在块内逐行判断（回表 or 过滤）
WHERE a = 1 AND b IN (2,3) AND c = 3：
b IN是等值列表，仍可继续用
(a,b)，但
c依然不参与索引查找（除非覆盖索引） 想让
c也生效？要么补上
b，要么把
c提前到索引左边（但得看查询模式是否真需要）
建联合索引时，字段顺序不是随便排的
顺序错了，等于白建。核心就两条：高频等值查的放最左，高区分度的优先靠前。比如用户登录表有
login_name和
status，
login_name唯一性强、几乎每次查询都带，
status只有“启用/禁用”两个值——那必须
INDEX(login_name, status)，反过来就废了。 错误示例：
INDEX(status, login_name)→
WHERE login_name = 'x'完全无法使用 排序需求也要考虑：如果常
ORDER BY create_time DESC，且总带
user_id查询，建议
INDEX(user_id, create_time)（注意方向一致，否则可能触发
filesort） 覆盖索引场景：若只查
SELECT user_id, create_time FROM orders WHERE user_id = 123，
INDEX(user_id, create_time)就能避免回表
怎么确认你的 SQL 真的命中了联合索引？
别猜，用
EXPLAIN看执行计划。重点盯三个字段：
key（是否显示索引名）、
key_len（用了索引多少字节）、
Extra（有没有
Using index或
Using where; Using index）。
EXPLAIN SELECT * FROM student WHERE Gid = 1 AND Cid = 2;→ 若索引是
uni_Gid_Cid_SId(Gid,Cid,SId)，
key_len应为前两列长度之和
EXPLAIN SELECT SId FROM student WHERE Gid = 1;→ 若
Extra出现
Using index，说明走了覆盖索引（只读索引叶节点，不回表） 如果
key是
NULL，或
type是
ALL，基本就是没走索引，回头检查条件是否跳过了最左列
实际调优时，最易被忽略的不是“会不会用”，而是“用了多少”——
key_len少几个字节，可能意味着少走了一层索引深度，也可能意味着丢了排序能力或覆盖能力。别只看“有没有”，要看“用到了哪一层”。
