联合索引的最左前缀匹配到底怎么生效
MySQL 的联合索引不是“只要查了其中一列就走索引”，而是严格按定义顺序做最左前缀匹配。
KEY idx_name_age_status (name, age, status)这个索引，只有以下查询能用上索引的全部或部分能力：
WHERE name = 'Alice'→ 用到
name列
WHERE name = 'Alice' AND age = 25→ 用到
name, age
WHERE name = 'Alice' AND age = 25 AND status = 'active'→ 全部三列都用上
WHERE name = 'Alice' AND status = 'active'→ 仍只用到
name，
status不会跳过
age单独走索引
一旦中间某列没出现在
WHERE条件中（比如缺失
age），后续列就失效。这是最容易误判的地方：以为“有索引列在条件里就能用”，其实顺序和连续性才是关键。
ORDER BY 和 GROUP BY 能不能复用联合索引
能，但必须完全匹配最左前缀，且排序方向一致（全 ASC 或全 DESC）。例如索引
idx_user_city_regtime (user_id, city, reg_time)：
ORDER BY user_id, city→ 可用，覆盖前两列
ORDER BY user_id DESC, city ASC→ MySQL 8.0+ 支持混合方向，但 5.7 及更早版本会直接放弃索引排序，改用 filesort
ORDER BY city, reg_time→ 不行，没带
user_id，不满足最左前缀
GROUP BY user_id, city ORDER BY reg_time→
GROUP BY部分可用索引，但
ORDER BY reg_time是额外字段，无法避免排序
注意：
SELECT * FROM t WHERE city = 'Beijing' ORDER BY reg_time这类查询，即使
city在联合索引第二位，也基本不会走该索引——因为没走最左列，优化器大概率选全表扫描或单列索引（如果有的话）。
联合索引里要不要包含主键
一般不用显式包含。InnoDB 的二级索引叶子节点自动存主键值（聚簇索引引用），所以
SELECT id FROM t WHERE name = 'Alice'这种查询，哪怕索引是
(name)，也能回表拿到
id；而
SELECT name, age FROM t WHERE name = 'Alice'如果建的是
(name, age)覆盖索引，就根本不用回表。 显式把主键加进联合索引（如
(name, id)）是冗余的，浪费空间，还可能干扰最左匹配逻辑 真正该考虑的是「覆盖索引」：把 SELECT 中所有需要的列都放进索引末尾，避免回表。比如常用
SELECT name, age, status FROM user WHERE name = ? AND age > ?，那就建
(name, age, status)，而不是硬塞一个
id
多一列主键进去，索引体积变大，维护成本升高，但收益为零。
IN 查询对联合索引的影响很微妙
IN在最左列上表现接近等值查询，但一旦出现在非最左位置，效果骤降。以
idx_a_b_c (a, b, c)为例：
WHERE a IN ('x', 'y') AND b = 10 → a和
b都能走索引（MySQL 5.7+ 对 IN + 等值组合做了优化）
WHERE a = 'x' AND b IN (1, 2, 3) AND c = 100→
a和
b有效，
c仍可用（因
b IN后还能继续匹配）
WHERE a = 'x' AND c = 100→
c完全失效，因为跳过了
b
WHERE b IN (1,2) AND c = 100→ 整个联合索引几乎无效，优化器大概率放弃它
IN 本身不破坏最左原则，但它会让范围扫描提前终止后续列的精确匹配。实际执行时可用
EXPLAIN看
key_len值变化，比凭感觉判断可靠得多。
