复合索引字段顺序应按查询模式确定：高频等值字段最左，范围查询字段居中且仅一个，排序/分组字段紧随其后以满足最左连续性，否则索引失效。
复合索引字段顺序怎么定才不白建
最左前缀匹配不是“从左边开始能用几个用几个”，而是「严格连续匹配索引定义的前缀」。你建了 (a, b, c)，WHERE b = 1 AND c = 2 一条都用不上——a 没出现，整个索引直接失效。
实际选序得看查询模式：高频等值过滤字段放最左，范围查询（>、BETWEEN）字段放等值字段之后且只放一个，排序字段（ORDER BY）尽量紧接在等值字段后面，避免额外排序。
-
a = ? AND b > ? ORDER BY c→ 索引应为(a, b, c)，c才能用于排序 -
a = ? AND c = ? ORDER BY b→(a, b, c)中b在中间，但c是等值且跳过了b，ORDER BY b无法利用索引排序，会触发Using filesort - 有
GROUP BY时同理，分组字段也需满足最左连续性
ORDER BY 走索引排序的硬性条件
MySQL 只有在索引能「覆盖 WHERE 过滤 + ORDER BY 排序」两个动作时，才免排序。否则哪怕 WHERE 用了索引，ORDER BY 仍会回表后二次排序。
关键看执行计划里的 Extra 字段：出现 Using filesort 就说明没走索引排序。
- WHERE 用
(a, b)，ORDER BYc→ 不行，c不在索引前缀里 - WHERE 用
a = ?，ORDER BYb, c→ 行，前提是索引是(a, b, c) - ORDER BY 含非索引字段、或方向混用（如
ORDER BY b ASC, c DESC但索引是(b, c)默认都是 ASC）→ 多数版本不支持混合方向索引排序，会退化
LIKE '%xxx' 为什么让前面的索引字段也失效
因为最左前缀匹配一旦遇到范围/模糊查询（LIKE 前导通配符、>、<），后续字段就断了。不是“部分失效”，是「从该字段起，右边全作废」。
比如索引 (a, b, c)，查询 WHERE a = 1 AND b LIKE '%test' ORDER BY c：虽然 a 是等值，但 b 是左模糊，c 完全无法用于排序或过滤。
- 想让
c参与排序？必须把b改成等值（b = 'xxx'）或右模糊（b LIKE 'test%'） - 真要查中间匹配，考虑全文索引或
GENERATED COLUMN + INDEX预处理子串 - EXPLAIN 时注意
key_len值：它反映实际用到索引字节数，b LIKE '%x'下key_len可能只包含a的长度
联合索引里要不要包含 SELECT 的字段
要看是否需要避免回表。如果查询只涉及索引字段（即「覆盖索引」），MySQL 直接从索引 B+ 树叶子节点取数据，不查主键聚簇索引。
但加太多字段进索引会增大体积、拖慢写入，得权衡。
- 高频查询如
SELECT id, name FROM t WHERE status = 1 ORDER BY created_at→ 索引(status, created_at, id, name)可覆盖，无回表 - 如果
name很长（比如 TEXT），放进索引可能得不偿失，不如只索引(status, created_at, id)，靠主键回表取name - 注意：主键字段自动包含在二级索引中，所以
id是主键时，(status, created_at)索引里已有id，无需显式重复加
key_len 和 Extra 里的 Using filesort 或 Using temporary。 
