MySQL 复合索引字段顺序需按查询频率、选择性(高区分度优先)、WHERE/ORDER BY/GROUP BY 使用模式确定,遵循最左前缀原则,兼顾覆盖索引以减少回表。

MySQL 复合索引的字段顺序不是随便排的,核心在于让索引真正被用上——既要满足查询条件匹配,又要支撑排序、分组等操作。顺序错了,哪怕建了索引也可能完全失效。
按查询条件的使用频率和选择性排
高频、高区分度的字段优先放前面。比如用户表中 user_id(唯一、高频)比 gender(低区分度、常为“男 / 女”二值)更适合做联合索引首列。选择性越高(即去重后值越多),索引过滤效率越高。可粗略用 COUNT(DISTINCT col) / COUNT(*) 估算。
- 先看 WHERE 中哪些字段最常单独或组合出现
- 若
WHERE status = ? AND category = ?频繁,但status只有 3 个值,而category有 200+,则category更适合作首列 - 避免把低选择性字段(如 is_deleted、state)放在最左位,否则索引利用率极低
兼顾 ORDER BY 和 GROUP BY 的列顺序
如果查询带 ORDER BY a, b,且 WHERE 条件含 a = ?,那么 (a, b) 这样的顺序能让排序直接走索引(Using index),避免 filesort。前提是:
- ORDER BY 列必须是索引的连续前缀,且方向一致(全 ASC 或全 DESC)
- 不能跨过 WHERE 中未使用的中间列,例如索引是
(a, b, c),WHERE 用了a,ORDER BY 用b, c可以;但只用c排序就无效 - 如果 SELECT 中还有其他非索引字段,需评估是否回表代价过大——此时宁可拆分索引或覆盖索引
遵循最左前缀原则,不跳列
联合索引 (A, B, C) 实际等效于三个索引:(A)、(A, B)、(A, B, C)。但无法支持 B = ? 或 C = ? 单独查询,也不能支持 A = ? AND C = ?(跳过了 B)。
- WHERE 中必须包含最左列,后续列才可能生效
-
A = ? AND B > ? AND C = ?:C 仍可用,因为 A、B 已满足前缀,且 B 是范围查询,C 在其后仍可做索引过滤(但注意:B 之后的等值列仅在某些版本 / 场景下生效,稳妥起见建议等值列前置) - 写查询时,条件顺序不影响索引使用(
WHERE B = ? AND A = ?和WHERE A = ? AND B = ?效果一样),但建索引时顺序决定一切
考虑覆盖索引,减少回表
如果经常执行 SELECT id, name, status FROM t WHERE status = ? ORDER BY create_time,可以建索引 (status, create_time, id, name)——把 SELECT 所需字段全包含进去,这样查完索引树就直接返回结果,无需回主键查找(Using index,非 Using index condition)。
- 覆盖索引能同时优化 WHERE + ORDER BY + SELECT,但字段多了会增大索引体积,需权衡
- 主键自动包含在二级索引中,所以
(status, create_time)索引已隐含主键,若 SELECT 只要 id,无需额外加 id - TEXT、BLOB 类型不能建索引,大 VARCHAR 建索引需指定前缀长度,也影响覆盖效果






























