联合索引 INDEX(a,b,c) 实际构建 (a)、(a,b)、(a,b,c) 三棵 B+ 树，遵循最左前缀原则：WHERE a=1 走 (a)，WHERE a=1 AND b>10 走 (a,b)，WHERE b=2 或 WHERE c=3 则全表扫描；字段顺序影响索引有效性，高频等值列须放最左，高区分度优先靠前。
联合索引不是“多个字段拼一起”，而是按顺序建的三棵子索引树
很多人误以为 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 少几个字节，可能意味着少走了一层索引深度，也可能意味着丢了排序能力或覆盖能力。别只看“有没有”，要看“用到了哪一层”。
