explain出现using temporary说明group by明确未走索引分组路径，而是强制建临时表处理；根本原因是索引未覆盖where条件、group by字段顺序及select非聚合字段，或存在函数、隐式转换等导致索引失效。
EXPLAIN里出现Using temporary就说明GROUP BY没走索引
只要执行计划中Extra字段包含Using temporary，基本可以断定MySQL正在用磁盘或内存临时表做分组——索引没被用于分组阶段。这不是“可能没走”，而是明确失效。此时key字段即使显示有索引名，也只代表WHERE过滤用了索引，不代表GROUP BY过程受益。
常见误判点：
- 看到
type: index就以为走了索引——其实这是全索引扫描，和全表扫描（ALL）性能接近，且仍会触发Using temporary -
key_len值偏小，比如定义了(status, city, age)索引，但key_len只显示status长度——说明后续字段根本没参与查找 - 没开
FORMAT=TRADITIONAL或FORMAT=TREE，漏看物化节点（尤其在视图或子查询场景下）
GROUP BY字段顺序必须严丝合缝匹配索引最左前缀
索引(a, b, c)能支撑GROUP BY a、GROUP BY a, b、GROUP BY a, b, c，但对GROUP BY b, c或GROUP BY c完全无效。B+树结构决定了只有最左连续字段才能保证物理有序性，而GROUP BY依赖的就是这个有序性来避免排序。
实际建索引时要注意：
- 如果SQL是
WHERE region = 'CN' GROUP BY category, subcategory，索引必须是(region, category, subcategory)，不能是(category, subcategory)或(region, subcategory, category) - 高基数字段（如
email）放右边，低基数字段（如status）放左边，利于范围过滤后快速定位分组边界 - 视图里定义了
GROUP BY x, y，你再对外层加GROUP BY y, x，几乎必然触发物化——优化器不会帮你重排
函数、类型转换、隐式比较会让索引直接失效
任何在GROUP BY字段或WHERE条件中对索引列施加的计算，都会打断B+树的有序访问路径。MySQL不会为每次查询动态重建索引，只能退回到全表扫描。
典型踩坑写法：
-
GROUP BY YEAR(create_time)→ 改用WHERE create_time >= '2026-01-01' AND create_time + <code>GROUP BY create_time（配合生成列或分区更稳） -
WHERE user_id = '12345'（user_id是BIGINT）→ 字符串转数字引发隐式转换，索引失效；必须传12345 -
GROUP BY UPPER(name)或GROUP BY CONCAT(first_name, ' ', last_name)→ 无法命中普通索引；需提前冗余字段并建索引 -
WHERE name LIKE '%john'→ 后缀模糊不走索引；前缀匹配LIKE 'john%'才可以
视图或子查询会让GROUP BY彻底脱离基表索引
你以为在对视图v_sales做GROUP BY region，其实优化器早已把它重写成SELECT * FROM (SELECT ... FROM sales ...) AS v GROUP BY region。中间结果集没有聚簇顺序，也没有你为sales表建的任何索引。
确认是否被物化的关键信号：
- MySQL 8.0+：执行
EXPLAIN FORMAT=TREE SELECT * FROM v GROUP BY x，看到MATERIALIZE节点 - PostgreSQL：用
EXPLAIN (VERBOSE)，出现Subquery Scan或Materialize - SQL Server：普通视图不支持索引，只有带
SCHEMABINDING和唯一聚集索引的索引视图才可能复用，且查询需严格匹配、会话选项全开
真正容易被忽略的是：索引建得再完美，只要上层SQL引入了不可内联的结构（比如视图含DISTINCT、UNION、窗口函数），GROUP BY就永远在跟临时表打交道。
