直接看explain的extra列：出现using temporary说明mysql正用临时表分组，性能已严重下降；出现using filesort表示无法利用索引顺序完成分组或排序，必须额外排序。
怎么看执行计划里有没有临时表或文件排序
直接跑 EXPLAIN，重点盯 Extra 列：
- 出现
Using temporary：MySQL 正在建内存或磁盘临时表存分组中间结果，说明它无法靠索引顺序直接分组 - 出现
Using filesort：即使有索引，也无法支撑 GROUP BY 所需的物理顺序，必须额外排序（哪怕你没写ORDER BY） -
key为空或显示NULL：压根没走索引，全表扫描起步，临时表和排序必然跟上 -
type是index不代表安全——它只表示扫了索引，不代表能跳过排序或临时表
为什么加了索引还是出 Using temporary
索引存在 ≠ 能用于 GROUP BY。常见硬伤：
-
GROUP BY a, b，但索引是(b, a)或(a)单列 → 不匹配最左前缀，无法利用索引天然有序性 -
SELECT status, SUM(amount)，索引只建了(status)→amount得回表查，MySQL 认为不如全扫+临时表更省事 -
WHERE created_at > '2024-01-01'是范围条件，放在联合索引中间（如(shop_id, created_at, user_id)）→user_id部分索引用不上，后续GROUP BY user_id失效 -
WHERE user_id = '123'（user_id是BIGINT）→ 隐式类型转换导致索引失效，连带 GROUP BY 失去依托
怎么确认是不是覆盖索引生效了
覆盖索引不是“有索引就行”，而是要让 MySQL 完全不用回表：
-
EXPLAIN中key显示用了某个索引，且Extra里没有Using temporary和Using filesort -
SELECT的所有字段（含GROUP BY列、聚合函数依赖的非分组列）都必须在该索引定义中 - 例如
SELECT category, COUNT(*), MAX(note)GROUP BY category，索引至少得是(category, note)；只建(category)不算覆盖 - MySQL 5.7 不支持函数索引，
GROUP BY DATE(created_at)必须靠生成列 + 索引；8.0 可直接建INDEX (DATE(created_at))
ORDER BY NULL 真的有用吗
有用，但作用有限，别指望它救全场：
- 加
ORDER BY NULL能干掉Using filesort，前提是Using temporary已消失——否则只是少排一次序，临时表还在吃内存 - 如果
Extra同时有Using temporary和Using filesort，加或删ORDER BY NULL都不会明显变快 - 某些客户端（比如 SQLyog）会偷偷优化掉排序逻辑，导致本地快、服务器慢，别被这种假象骗过去
- 真正该盯的是
Using temporary——只要它还在，说明分组逻辑本身低效，调参或加ORDER BY NULL都是隔靴搔痒
tmp_table_size 和 max_heap_table_size，但调大参数只是缓解症状；真正的瓶颈往往藏在索引顺序与查询结构的错位里——而这个错位，EXPLAIN 一眼就能戳穿。
