组合索引字段顺序颠倒会导致最左前缀匹配完全失效，因b+树按索引定义顺序构建物理结构，顺序改变即树结构不同；如索引(a,b,c)无法支持where b=2或order by b,a等查询，必须按访问模式将高频等值字段置最左，范围字段靠右，排序/分组字段紧随且顺序一致。

MySQL 组合索引字段顺序一旦颠倒，最左匹配就可能完全失效——不是“效果变差”，而是“根本用不上”。

关键不在 SQL 里 WHERE 条件怎么写，而在于索引本身怎么建。B+ 树只按你定义的最左字段构建主排序路径，后续字段只是在前一列值相等的前提下做次级排序。顺序一换，物理结构就变了。

组合索引字段顺序颠倒，直接导致无法命中最左前缀

• 索引 (a, b, c) 表示：先按 a 全局排序；a 相同时，再按 b 排序；a 和 b 都相同时，再按 c 排序
• 索引 (b, a, c) 则是：先按 b 全局排序；b 相同时，再按 a 排序……物理结构完全不同

所以：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• WHERE a = 1 AND b = 2 —— 能用 (a, b, c)，但不能用 (b, a, c) 做高效查找（因为 b 不是查询条件，a 又不是最左列，树没法从 a 开始定位）
• WHERE b = 2 AND a = 1 —— 能用 (b, a, c)，但不能用 (a, b, c) 的 b 部分做起点（a 是最左，但 b 单独出现时，a 没提供约束，整个索引无法起步）

MySQL 查询优化器会重排 WHERE 子句顺序，但它不会、也不能把 (a,b,c) 索引“当(b,a,c)用”。索引结构是静态的，优化器只能选已有索引，不能动态重组。

颠倒顺序后，哪些查询彻底失效？

• WHERE b = 2 → 对 (a,b,c) 索引：全表扫描（b 不是最左，无法定位起始页）
• WHERE b = 2 AND c = 3 → 同样全表扫描（跳过最左列 a，链路断裂）
• WHERE a = 1 AND c = 3 → 只能用上 a，c 不走索引（中间缺了 b，不满足连续最左前缀）
• ORDER BY b, a → 对 (a,b,c) 索引：触发 Using filesort（排序字段顺序与索引不一致，无法复用物理顺序）
• GROUP BY b → 对 (a,b,c) 索引：无法避免临时表和排序（b 不在最左，索引有序性对分组无效）

怎么避免因顺序颠倒踩坑？

• 先明确访问模式：哪个字段常用于等值过滤？哪个是范围条件？哪个用于分组或排序？
• 等值条件字段优先放最左（如 shop_id = ?）
• 多个等值条件，把区分度高（选择性好）的放前面（比如 status 只有 3 个值，user_id 有百万值，后者更适合作最左）
• 范围条件（>, , <code>BETWEEN, LIKE 'abc%'）必须放等值字段之后，且它之后的字段索引失效
• GROUP BY 或 ORDER BY 字段，必须紧接在等值过滤字段之后，并保持相同顺序

例如查询：

SELECT user_id, COUNT(*) 
FROM orders 
WHERE shop_id = 123 AND created_at >= '2024-06-01' 
GROUP BY user_id;

推荐索引：(shop_id, user_id, created_at)
错误索引：(created_at, shop_id, user_id) —— created_at 是范围，导致后面两列几乎无法利用

索引字段顺序不是语法偏好，而是对 B+ 树搜索路径的硬性约定。颠倒，就是重建一棵不同的树。