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 建索引需指定前缀长度，也影响覆盖效果
