SQL 为什么索引顺序如此重要？_技术教程

复合索引只支持最左前缀匹配，字段顺序不一致将导致索引失效，如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 > '2025-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) 有效得多——前者支持租户隔离 + 时间筛选，后者连租户过滤都走不了最左匹配。