GROUP BY字段顺序必须与索引最左前缀严格一致才能命中索引，否则触发Using temporary或filesort；如索引(department, city)不支持GROUP BY city, department，且MySQL优化器不会自动重排GROUP BY字段匹配索引。
GROUP BY字段顺序影响索引是否命中
MySQL优化器不会自动重排 GROUP BY 字段去匹配已有索引。如果你写的是 GROUP BY city, department，但只建了 INDEX idx_dept_city (department, city)，这个索引就完全用不上——因为最左前缀不匹配。
索引生效的前提是：查询中 GROUP BY 的字段顺序、方向（ASC/DESC）、数量，必须与索引定义严格一致（MySQL 8.0+ 支持混合方向，但需显式声明）。
- ✅ 正确匹配：
GROUP BY user_id, status+INDEX idx_user_status (user_id, status) - ❌ 不匹配：
GROUP BY status, user_id即使索引存在，也会触发Using temporary - ⚠️ 方向错位：
GROUP BY user_id DESC, status ASC需要INDEX ... (user_id DESC, status ASC)，否则降序部分可能退化为 filesort
多字段分组时，顺序决定分组策略选择
MySQL默认优先走排序分组（Sort-based GROUP BY），前提是数据能按索引顺序物理读取。如果 GROUP BY a, b 有对应索引，扫描时自然就是先按 a 排好、再在每个 a 内按 b 排好，分组过程可流式完成，不建临时表。
一旦顺序颠倒，比如实际数据按 b 有序但你要按 a, b 分组，MySQL无法跳着归并，只能退回到哈希或强制排序，内存不够就落盘，Using temporary; Using filesort 就出现了。
- 索引顺序 = 分组逻辑顺序 → 可流式分组，常驻内存
- 索引顺序 ≠ 分组顺序 → 必须缓存全部中间结果再处理，易爆内存或写磁盘临时表
- EXPLAIN 中
Extra列出现Using temporary是最直接信号
WHERE + GROUP BY 混合时，字段顺序还牵扯最左前缀生效
复合索引不是“包含所有字段就行”，而是从左到右逐列生效。例如查询：SELECT dept, COUNT(*) FROM emp WHERE team = 'backend' GROUP BY dept, role，理想索引是 INDEX idx_team_dept_role (team, dept, role)。
这里 team 在最左，满足 WHERE 过滤；dept, role 紧跟其后，满足 GROUP BY 流式分组。如果把 role 放前面，team 就无法利用最左前缀，WHERE 条件失效，全表扫描立刻回来。
- WHERE 条件列必须放在 GROUP BY 列左侧（除非你明确不需要 WHERE 走索引）
- 如果还有
ORDER BY dept，那dept必须在索引中靠左，且不能被跳过 - 不要为了“看着顺”调换字段顺序，每换一个位置，都可能让整条索引失效
ORDER BY 和 GROUP BY 共存时，顺序冲突会双重惩罚
当语句同时含 GROUP BY a, b 和 ORDER BY b, a，即使两个字段都在索引里，只要顺序不一致，MySQL 就无法复用同一份有序数据：分组需要 a→b 顺序，排序又要 b→a 顺序，二者不可兼得。
结果就是：先用索引做分组（生成中间结果），再对中间结果单独排序（Using filesort）。大数据量下，这比单走一次全表还慢——因为中间结果集本身可能很大，排序成本远高于原始表扫描。
- 能合并的尽量合并：
GROUP BY a, b ORDER BY a, b可被单索引覆盖 - 无法合并时，优先保
GROUP BY（分组不可跳过），ORDER BY移到应用层做 - 别指望 MySQL 自动优化这种顺序矛盾；它不做语义等价推导，只认字面顺序
