最该盯住的三列是type、key、extra：type为all或index说明未走有效索引，key为null表示完全未用索引，extra出现using temporary或using filesort则表明分组被迫创建临时表或额外排序。
EXPLAIN里最该盯住的三列：type、key、Extra
GROUP BY慢不慢，执行计划里这三列说了算。别被12列输出吓住，type告诉你有没有走索引，key告诉你到底用了哪个索引，Extra直接暴露底层动作——它俩一出问题，性能基本就掉坑里了。
重点关注：type要是ALL或index，说明没走有效索引；key为NULL等于完全没用索引；Extra里一旦出现Using temporary或Using filesort，就是分组没走索引、被迫在内存或磁盘上硬建临时表+排序。
-
Using temporary：MySQL必须建临时表存中间分组结果，哪怕数据只有百万级，一落盘就秒变I/O瓶颈 -
Using filesort：分组后还要按GROUP BY字段再排一次序（哪怕没写ORDER BY），说明索引顺序和分组顺序不匹配 -
Using index出现在Extra里是好事，代表只读索引不回表，但得配合key非NULL才真有效
GROUP BY字段顺序和索引顺序必须严格一致
建索引不是把GROUP BY里的字段都塞进去就行。GROUP BY user_id, status，就得建INDEX idx_group (user_id, status)，反过来建(status, user_id)几乎没用——因为MySQL只认最左前缀匹配，且分组阶段需要按字段顺序逐层哈希或排序。
如果还有WHERE条件，优先把过滤性强的字段放索引前面。比如WHERE status = 'active' GROUP BY user_id，那INDEX idx_where_group (status, user_id)比(user_id, status)更稳。
- 联合索引字段顺序必须和
GROUP BY子句字段顺序完全相同，差一个位置，索引就大概率失效 -
key_len值要对得上：比如VARCHAR(255)字段实际只用前10字符，key_len应≈30（utf8mb4下每个字符占4字节），若显示765，说明索引定义和查询条件长度不匹配 - 避免在
GROUP BY字段上套函数，GROUP BY DATE(created_at)会让整个索引失效，改用冗余日期字段+范围查询更可靠
tmp_table_size不够时，临时表会悄悄落盘
MySQL默认把小临时表放内存，超限就写到磁盘成MyISAM临时表，SHOW PROCESSLIST里看到Copied to tmp table on disk就是信号——I/O拖垮性能的开始。
查当前设置：SELECT @@tmp_table_size, @@max_heap_table_size;。两个值需同步调大，否则以较小者为准。线上大表分组建议设到256M以上，但别盲目堆高，得结合服务器内存总量评估。
- 单次
GROUP BY结果行数越多，临时表越大；分组键基数越高（如用户ID），越容易突破阈值 -
SQL_BIG_RESULT提示可强制MySQL提前用磁盘临时表，避开内存溢出风险，但代价是稳定慢一点，适合已知结果集巨大的场景 - 调参只是兜底手段，真正治本还是靠索引让分组过程不生成临时表
别忽略WHERE和GROUP BY的协同关系
很多人只盯着GROUP BY字段建索引，忘了WHERE条件才是第一道筛子。如果WHERE本身没走索引，扫描几百万行才进分组阶段，再好的分组索引也救不回来。
用EXPLAIN FORMAT=TRADITIONAL看完整执行链：先确认WHERE是否高效（type至少是range或ref），再看GROUP BY是否复用同一索引（key值一致、key_len合理），最后检查Extra有没有甩掉Using temporary。
-
possible_keys有多个但key只选其一？可能是统计信息过期，运行ANALYZE TABLE 表名更新下 -
rows远大于实际返回行数？说明索引没覆盖查询条件，或条件写法导致索引失效（比如LIKE '%abc'） - 复合索引中
WHERE字段和GROUP BY字段共用一个索引时，顺序安排是关键，不是谁先谁后的问题，而是“过滤强的放左，分组字段紧随其后”的实操逻辑
Using temporary——它背后藏着索引没对齐、参数没调够、WHERE没压住数据量三重隐患。盯住EXPLAIN输出，比凭经验加索引靠谱得多。
