EXPLAIN出现Using temporary说明GROUP BY未利用索引有序性而强制走临时表路径；关键看Extra字段是否含该提示，而非仅key是否有值，高效执行需type为ref/range、key命中且Extra为空或仅Using index。
EXPLAIN 里出现 Using temporary 就说明 GROUP BY 没走索引
只要 EXPLAIN 的 Extra 列里有 Using temporary（哪怕同时显示 key 有值），就代表 MySQL 放弃了索引分组能力，改用临时表做聚合——这不是“部分走索引”，而是分组逻辑彻底没利用索引有序性。
常见误判是看到 key: idx_user_id 就以为走了索引，其实关键看 Extra：如果同时带 Using temporary; Using filesort，说明索引只被用于定位或扫描，但分组本身仍靠内存/磁盘临时结构完成。
-
type是index或range只说明用了索引扫描，不等于支持分组 -
Using index表示覆盖索引，但若伴随Using temporary，仍属低效路径 - 真正高效的表现是：
type为ref/range、key显示目标索引、Extra为空或仅Using index
GROUP BY 字段顺序和索引字段顺序必须完全一致
MySQL 不会自动重排字段顺序来匹配索引。哪怕你建了 INDEX idx_dept_time (dept_id, created_at)，写成 GROUP BY created_at, dept_id 也完全无法触发 Loose Index Scan。
索引生效的前提是：GROUP BY 列必须是索引的最左连续前缀，且顺序严格对应。跳过前导列、调换顺序、中间插入非等值条件，都会中断有序性。
-
GROUP BY dept_id→ 可用(dept_id, created_at) -
GROUP BY dept_id, created_at→ 同样可用该索引 -
GROUP BY created_at→ 即使索引含该列，也无法用（不是最左） -
WHERE status = 'active' GROUP BY dept_id→ 理想索引是(status, dept_id)，而非单独dept_id
ORDER BY 和 HAVING 会悄悄破坏索引分组能力
加 ORDER BY 不一定坏事，但加错字段就会让优化器直接放弃索引分组。比如 GROUP BY dept_id ORDER BY name，只要 name 不在 GROUP BY 列表里，也不属于确定性聚合（如 MAX(name)），MySQL 就无法保证每组输出唯一可比值——此时连语义校验都通不过，根本不会进入索引排序决策。
更隐蔽的是 HAVING：哪怕写 HAVING 1=1 这种恒真条件，也可能干扰优化器对执行路径的判断，导致它绕过 Loose/Tight Index Scan 而选临时表。
- 安全的
ORDER BY：只能是GROUP BY列本身，或确定性聚合表达式（如ORDER BY MAX(created_at)） - 带
HAVING的查询，优先检查是否真需要过滤聚合结果；若只是占位，删掉更稳妥 - 子查询里写
ORDER BY在 MySQL 5.7+ 基本无效——derived_merge优化会直接丢弃它
函数、类型转换、SELECT * 都会让索引失效
任何对 GROUP BY 字段的包装操作，都会切断索引与原始值的映射关系。MySQL 无法在 B+ 树上直接定位 UPPER(name) 或 DATE(create_time) 的有序序列，只能全表计算后再分组。
同样，SELECT * 或未被索引覆盖的非聚合字段（如 SELECT dept_id, name, COUNT(*)），会迫使 MySQL 回表取数据，一旦回表量大，优化器往往主动退回到临时表路径。
-
GROUP BY UPPER(name)→ 索引失效（函数） -
WHERE user_id = '123'（user_id 是 INT）→ 隐式类型转换，索引失效 -
SELECT dept_id, name, COUNT(*) FROM emp GROUP BY dept_id→ 若name不在索引中，大概率触发Using temporary - MySQL 5.7 不支持函数索引，
GROUP BY DATE(create_time)必须靠生成列 + 索引实现
索引本身不会“拒绝” GROUP BY，但只要 SQL 写法破坏了索引的最左前缀连续性、有序性或覆盖性，优化器就会当场放弃。真正要调的不是参数，而是建索引的顺序、写的字段顺序、以及有没有在字段上动手脚。
