联合索引严格遵循最左前缀匹配：只有从左开始连续的列出现在查询条件中才能生效，中间缺失则后续列失效；ORDER BY/GROUP BY 也需满足该原则且方向一致；主键无需显式加入联合索引，应优先考虑覆盖索引；IN 在最左列表现良好，但非最左位置会显著降低索引效率。
联合索引的最左前缀匹配到底怎么生效
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 值变化，比凭感觉判断可靠得多。
