多列索引字段顺序不能随便调换，因b+树按顺序逐层排序：等值查询字段（=、in）应置前，范围查询（>、between等）须在等值之后且使后续字段失效；order by/group by需与索引顺序完全一致才免排序；覆盖索引应包含where条件和select字段，避免回表；验证需结合explain的key_len和extra字段。
多列索引字段顺序为什么不能随便调换
mysql 的 B+ 树索引是按字段顺序逐层排序的，WHERE a = ? AND b = ? 能用上 (a, b) 索引，但换成 WHERE b = ? 就完全失效——因为树的第一层只存了 a 的值，b 是第二层才分叉的。
常见错误现象：EXPLAIN 显示 type: ALL 或 key: NULL，明明建了索引却没走。
- 等值查询字段（
=、IN）放最前，比如user_id = 123 AND status = 'active'→ 索引应为(user_id, status) - 范围查询字段（
>、BETWEEN、LIKE 'abc%'）只能放在等值字段之后，且后面所有字段都失效：索引(a, b, c)中WHERE a = 1 AND b > 100只能用上a和b，c不参与索引查找 - 排序和分组字段如果和索引顺序一致，可避免
using filesort；否则即使有索引也白搭
高频查询覆盖建议：哪些字段该塞进联合索引
不是“查得勤就加”，而是看查询是否能被单条索引语句完整覆盖——即 SELECT 所需字段全部来自索引本身，不回表。
使用场景：用户中心页查 id, name, avatar, updated_at，且常按 status 和 created_at 过滤。
- 优先覆盖
WHERE条件字段 +SELECT字段（尤其是大字段如TEXT、json），例如建(status, created_at, id, name, avatar) - 避免把
id放前面再加一堆其他字段——主键本身已是聚簇索引，重复冗余 - 注意
SELECT *天然无法被覆盖，除非你建的是包含所有列的索引（不现实，也不推荐） - 单表索引总数别超 6–8 个，太多会影响写入性能，
INSERT/UPDATE/delete都要维护所有相关索引
ORDER BY 和 GROUP BY 怎么和多列索引配合
MySQL 只有在索引顺序与 ORDER BY 字段完全一致（且方向全为 ASC 或全为 DESC）时，才能跳过排序步骤。混合方向（如 ORDER BY a ASC, b DESC）在 8.0 之前基本无效。
错误示例：INDEX (a, b)，查询 SELECT * FROM t WHERE a = 1 ORDER BY b DESC 在 MySQL 5.7 下仍会触发 Using filesort。
-
ORDER BY a, b→ 索引(a, b)完美匹配 -
ORDER BY b→ 即使有(a, b)索引也无用，除非加WHERE a = ?把扫描限定在单个a值内 -
GROUP BY a, b同理，且HAVING条件不会走索引，别指望它优化 - 如果业务真需要
ORDER BY b且无a过滤，单独建(b)或(b, a)更实际
如何验证你的多列索引真的生效了
光看 EXPLAIN 的 key 字段不保险，得看 key_len 和 Extra 细节。
典型误判：看到 key: idx_ab 就以为全用了，其实 key_len 只有 4 字节（只用了 a 的 int 长度），说明 b 没参与索引查找。
- 算
key_len：参考字段类型长度，TINYINT是 1，INT是 4，VARCHAR(255)是 255+2（含长度头），NOT NULL不加 1 字节，NULL加 1 - 检查
Extra：出现Using index表示覆盖索引；Using where; Using index是理想状态；Using index condition是 ICP（索引下推），也 OK；但Using filesort或Using temporary就得调索引或 SQL - 用
SHOW INDEX FROM table_name确认索引字段顺序和可空性，别依赖记忆或旧文档 - 线上慢查日志里抓真实
WHERE条件，别只按测试 SQL 设计索引
最麻烦的其实是隐式类型转换——比如 user_id 是 BIGINT，但代码传了字符串 '123'，MySQL 自动转类型会导致索引失效，这种问题不会报错，但 key_len 会异常小，得盯紧。