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