联合索引（Composite Index）是 MySQL 优化查询性能最常用的手段之一，而字段顺序的设计直接决定了这个索引能否被有效利用。很多面试题都会围绕这一点展开，比如“where a=1 and b=2 和 where b=2 and a=1 能否用到同一个联合索引”“为什么范围查询后面的字段用不到索引”等。本文从最核心的原则出发，把联合索引字段顺序的设计逻辑讲清楚。
一、最左前缀原则：联合索引的底层规则
联合索引 (a, b, c) 在 B+ 树中并不是三个独立的索引，而是按照 a 排序、a 相同再按 b 排序、b 相同再按 c 排序的方式组织数据。这意味着：
- 索引只能从最左列开始连续匹配。查询条件中缺少 a，只用 b 或 c，无法使用该索引。
- 一旦遇到范围查询（
>、<、between、like 'xxx%'），范围列之后的列无法继续用于索引定位，只能用于回表后的过滤或覆盖索引中的判断。
举个直观的例子。索引 (a, b, c)：
-- 能用到 a、b、c 三列
WHERE a = 1 AND b = 2 AND c = 3
-- 能用到 a、b，c 无法用于定位
WHERE a = 1 AND b = 2 AND c > 3
-- 只能用到 a，b 和 c 用不到
WHERE a = 1 AND b > 2 AND c = 3
-- 完全用不到该索引
WHERE b = 2 AND c = 3
注意 WHERE a = 1 AND b > 2 AND c = 3 这个场景：很多初学者以为 c 的条件写在 SQL 里就能被索引利用，实际上 b 已经是范围条件，B+ 树在 b 这一层已经无法保证 c 有序，所以 c 只能作为索引条件下推（ICP）在存储引擎层过滤，或者回表后过滤。
二、设计字段顺序的核心原则
1. 等值条件列放前面，范围条件列放后面
这是最重要的一条。等值查询能让后续列在 B+ 树中保持有序，范围查询会“截断”后续列的有序性。所以：
-- 索引应设计为 (status, create_time)
SELECT * FROM orders WHERE status = 1 AND create_time > '2024-01-01';
如果把顺序反过来 (create_time, status)，那么 create_time 的范围条件会让 status 无法用于索引定位，效果大打折扣。
2. 区分度高的列优先，但不要教条
区分度（cardinality / 总行数）越高，索引过滤效果越好。一般建议把区分度高的列放在前面。但这条原则要结合上一条使用：如果高区分度列是范围条件，而低区分度列是等值条件，通常仍应把等值列放前面。
比如 (gender, age) 和 (age, gender)，如果查询是 WHERE gender = 'M' AND age > 20，应该选 (gender, age)，因为 gender 等值、age 范围，符合“等值在前、范围在后”。虽然 gender 区分度低，但它能先缩小范围并保证 age 有序。
3. 考虑 ORDER BY 和 GROUP BY
如果查询带有排序或分组，联合索引的字段顺序如果能与 ORDER BY 的列顺序一致，就可以避免额外的 filesort。
-- 索引 (a, b) 可以同时满足过滤和排序
SELECT * FROM t WHERE a = 1 ORDER BY b;
-- 索引 (a, b) 无法直接满足，因为 b 是范围后无序
SELECT * FROM t WHERE a > 1 ORDER BY b;
ORDER BY 的列如果跟在等值条件列后面，可以利用索引有序性；如果跟在范围条件列后面，则无法利用。
4. 覆盖索引的考量
如果查询只需要索引中的列，联合索引可以做成覆盖索引，避免回表。这时字段顺序除了满足最左前缀，还要把 SELECT 中需要的列也纳入索引，顺序上优先保证 WHERE 和 ORDER BY 的可用性。
三、常见误区与面试陷阱
误区一：把区分度最高的列无脑放最左。 如果它是范围条件，放最左反而会导致后面的等值列失效。
误区二：认为 SQL 中条件的书写顺序影响索引使用。 MySQL 优化器会自动调整等值条件的匹配顺序，WHERE a=1 AND b=2 和 WHERE b=2 AND a=1 对索引 (a,b) 的使用是一样的。真正影响的是条件类型（等值 vs 范围），不是书写顺序。
误区三：索引列越多越好。 联合索引列过多会增加索引体积、降低写入性能，而且超出实际查询需要的列没有收益。一般控制在 3~5 列以内，按实际慢查询来设计。
误区四：忽略索引条件下推（ICP）。 MySQL 5.6 之后支持 ICP，范围列之后的列虽然不能用于定位，但可以在存储引擎层过滤，减少回表次数。面试中如果被问到“范围后面的列完全没用吗”，要答“不能用于索引定位，但可能通过 ICP 减少回表”。
四、一个完整的设计示例
假设有查询：
SELECT id, user_id, amount, create_time
FROM orders
WHERE user_id = 100 AND status = 1 AND create_time > '2024-01-01'
ORDER BY create_time DESC;
分析：
user_id、status是等值条件。create_time是范围条件，同时用于排序。- 区分度：user_id 通常高于 status。
设计索引 (user_id, status, create_time)：
- user_id 等值 → status 等值 → create_time 范围，完全符合最左前缀和“等值在前、范围在后”。
- create_time 在等值列之后保持有序，可以支持 ORDER BY。
- 如果 SELECT 只需要这几列，还可做成覆盖索引。
如果改成 (status, user_id, create_time)，在 user_id 区分度远高于 status 的情况下，索引扫描的行数可能更多，性能略差，但依然可用。实际选择时可以通过 EXPLAIN 对比 rows 和 key_len 来验证。
五、总结
联合索引字段顺序的设计可以归纳为一句话：在满足最左前缀的前提下，等值条件列在前、范围条件列在后，兼顾区分度、排序分组和覆盖索引需求。
具体步骤：
- 列出所有涉及该表的查询，提取 WHERE、ORDER BY、GROUP BY 中的列。
- 区分等值条件和范围条件，等值列优先。
- 在等值列内部，按区分度从高到低排列。
- 范围列和排序列放在等值列之后。
- 用
EXPLAIN验证key、key_len、rows，必要时调整。
面试中回答这类问题，不要只背“最左前缀”，而要能说清楚 B+ 树的有序性原理、范围查询为什么截断后续列、等值与范围的排列逻辑，以及 ICP 和覆盖索引的影响。把这些讲透，基本就能覆盖绝大多数联合索引相关的面试题。
未经允许不得转载：任鹏个人博客 » MySQL 联合索引字段顺序应该如何设计
