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 写法破坏了索引的最左前缀连续性、有序性或覆盖性，优化器就会当场放弃。真正要调的不是参数，而是建索引的顺序、写的字段顺序、以及有没有在字段上动手脚。