group by字段顺序必须严格匹配联合索引最左前缀才能避免临时表和文件排序；仅当分组列构成索引最左连续前缀且方向一致时，mysql才能利用b+树物理有序性边扫描边分组，否则触发using temporary或filesort。
GROUP BY 字段顺序必须严格匹配联合索引最左前缀
MySQL 能跳过临时表和文件排序（Using temporary; Using filesort），前提是 GROUP BY 的字段顺序、方向，与联合索引定义完全一致。B+Tree 叶子节点天然按索引列顺序物理排列，只要查询能“线性扫描”这一有序结构，就能边读边分组。
常见错误现象：
– 查询 GROUP BY col2, col1，但索引是 (col1, col2) → 不满足最左前缀，无法利用
– 索引是 (a, b)，查询写成 GROUP BY a DESC, b ASC → 方向不一致，低版本 MySQL 直接放弃索引
– 仅对 GROUP BY b 建单列索引，而实际需要 GROUP BY a, b → 仍触发 Using filesort
- 正确建法示例：查询
SELECT dept, role, COUNT(*) FROM staff GROUP BY dept, role→ 必须建INDEX idx_dept_role (dept, role) - 若还有
WHERE status = 1条件，优先把status放最左：建idx_status_dept_role (status, dept, role)，这样过滤+分组一步到位 - 避免把高基数列（如
id）放最左，除非它也是GROUP BY或WHERE条件——否则后续列的有序性会被稀释
覆盖索引能彻底避免回表，但 SELECT * 会立刻破坏它
只要 SELECT 的所有字段都包含在联合索引中，MySQL 就能直接从二级索引叶子节点取数，不用回聚簇索引查整行——这是消除 Using temporary 的关键一环。一旦用了 SELECT *，哪怕索引设计再完美，也会强制回表，导致优化器大概率弃用该索引。
- 推荐写法：
SELECT dept, role, COUNT(*) FROM staff WHERE status = 1 GROUP BY dept, role，配合索引idx_status_dept_role (status, dept, role) - 危险写法：
SELECT *, COUNT(*) FROM staff ...→ 即使索引含dept, role，*意味着要查所有列，必然回表，优化器倾向全表扫描 - 如果业务真要查多列，可把高频字段加进索引尾部，例如
(status, dept, role, salary, hire_date)，但注意索引宽度增加会拖慢写入
范围条件出现在 GROUP BY 前导列时，有序性立即中断
联合索引的有序性只在“等值条件连续命中前缀”的前提下成立。一旦前导列用了范围查询（>、、<code>BETWEEN、LIKE 'abc%'），后续列在物理存储上就不再全局有序，MySQL 无法保证扫描过程中 GROUP BY 字段天然分组，只能退回到临时表 + 排序流程。
- 这个行为和
ORDER BY完全一致：索引(a, b)，WHERE a = 1 GROUP BY b✅；WHERE a > 1 GROUP BY b❌ -
IN是特例：虽然语法像范围，但 MySQL 8.0+ 对短IN列表（如a IN (1,2,3)）可能走index_merge_union，仍能保持各分支内b有序，但不可依赖——实测需看EXPLAIN的Extra是否出现Using intersect或Using union - 替代方案：若必须范围过滤，考虑将范围列后置，或拆分查询（如先
WHERE a IN (...)查出主键，再用IN关联原表做分组）
GROUP BY 和 ORDER BY 共存时，索引要同时服务两者
当语句里既有 GROUP BY 又有 ORDER BY，且字段相同（如 GROUP BY a, b ORDER BY a, b），一个联合索引就能同时满足；但如果二者字段不同、顺序不同或方向冲突，优化器往往无法兼顾，最终退化。
- 安全组合：
GROUP BY a, b ORDER BY a, b→ 索引(a, b)即可 - 危险组合：
GROUP BY a, b ORDER BY b, a→ 无法共用一个索引，至少一个操作逃不开Using filesort - 升/降序混合：
GROUP BY a ASC, b DESC ORDER BY a ASC, b DESC→ MySQL 8.0+ 支持，但 5.7 不支持反向扫描，会失效 - 真正容易被忽略的一点：即使语法上没写
ORDER BY，MySQL 在某些场景下（如使用 SQL_BUFFER_RESULT）会隐式排序，也要纳入索引设计考量
