组合索引字段顺序颠倒会导致最左前缀匹配完全失效，因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有百万值，后者更适合作最左） - 范围条件（
>,<,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+ 树搜索路径的硬性约定。颠倒，就是重建一棵不同的树。
