复合索引只支持最左前缀匹配，字段顺序不一致将导致索引失效，如INDEX(a,b,c)无法用于WHERE b=2；等值查询字段应靠左，范围查询后列不可用；ORDER BY或JOIN条件顺序与索引不一致会引发filesort或全表扫描。
WHERE 条件里字段顺序和索引列顺序不一致会怎样
MySQL、PostgreSQL 等主流数据库在使用复合索引时，**只支持最左前缀匹配**。也就是说，INDEX (a, b, c) 可以加速 WHERE a = 1、WHERE a = 1 AND b = 2、WHERE a = 1 AND b = 2 AND c = 3，但对 WHERE b = 2 或 WHERE b = 2 AND c = 3 基本无效（除非是覆盖索引且优化器选择索引扫描，但不可靠）。
常见错误现象：EXPLAIN 显示 type: ALL（全表扫描），即使 WHERE 里用了索引字段，只是顺序不对。
- 复合索引不是“字段集合”，而是有严格位置依赖的有序结构
- 等值查询（
=）字段尽量靠左；范围查询（>、BETWEEN）之后的列无法走索引 - 例如
INDEX (status, created_at, user_id)中，WHERE status = 'active' AND created_at > '2024-01-01'只能用到前两列，user_id不会被用于索引查找
ORDER BY 和索引顺序冲突导致 filesort
如果 ORDER BY 的字段顺序或方向（ASC/DESC）与索引列顺序不一致，数据库大概率触发 Using filesort —— 这意味着要额外排序，严重拖慢分页或 LIMIT 查询。
例如，有索引 INDEX (category_id, score DESC)：
-
ORDER BY category_id, score DESC✅ 能直接利用索引完成排序 -
ORDER BY category_id, score ASC❌ 即使字段相同，方向相反也会 filesort（MySQL 8.0+ 对混合方向支持有限，仍需谨慎） -
ORDER BY score DESC, category_id❌ 字段顺序颠倒，索引失效
联合查询中 ON 条件顺序影响驱动表选择
在 JOIN 场景下，索引顺序会影响优化器是否能把某张表选为驱动表（即先查哪张表）。如果被驱动表的 ON 条件无法命中索引最左列，就可能被迫走嵌套循环全扫描，性能断崖式下跌。
比如 LEFT JOIN orders o ON u.id = o.user_id，若 orders 上建的是 INDEX (status, user_id)，而 ON 只用了 user_id，这个索引几乎没用——因为 user_id 不是最左列。
- 被驱动表的连接字段，必须是复合索引的最左列，或独立单列索引
- 多表 JOIN 时，优先为被驱动表设计“以连接列为最左”的索引，而非按业务查询习惯堆字段
- 用
EXPLAIN FORMAT=JSON查看key和used_key_parts，确认实际用了索引哪些部分
高基数字段放前面？不一定
很多人听说“把区分度高的字段放索引左边”就照搬，结果出问题。其实关键不是“高低基数”，而是**查询模式优先级**：哪个字段最常出现在等值过滤中？哪个字段最常和 ORDER BY 绑定？
例如用户表有 tenant_id（低基数，每租户几千条）和 created_at（高基数，时间戳），但业务查询永远带 tenant_id = ?，再加各种时间范围。这时候 INDEX (tenant_id, created_at) 比 INDEX (created_at, tenant_id) 有效得多——前者支持租户隔离 + 时间筛选，后者连租户过滤都走不了最左匹配。
- 基数只是参考，真实查询谓词（WHERE / JOIN / ORDER BY）的组合方式才是索引设计的唯一依据
- 写法上少用
SELECT *，避免让优化器放弃覆盖索引；明确列出需要字段，有助于判断是否可建覆盖索引 - 线上慢查一定要抓
EXPLAIN+ 实际执行计划，而不是仅凭字段基数拍脑袋
