GROUP BY字段无索引时几乎必然触发临时表；必须为分组字段建立匹配的单列或联合索引最左前缀，且ORDER BY字段需与GROUP BY严格一致才能避免Using temporary和filesort。
GROUP BY字段没索引，临时表几乎必然出现
只要GROUP BY的列上没有单列索引或联合索引的最左前缀，MySQL就无法流式分组，只能把所有匹配行读出来、建临时表、再哈希或排序分组。哪怕只有几千行，Using temporary也会稳稳出现在EXPLAIN的Extra里。
常见错误写法：SELECT region, COUNT(*) FROM orders WHERE status = 1 GROUP BY region，但只在status上有索引——这完全无效。MySQL必须先过滤再分组，而region无索引，就只能攒数据。
- 单字段
GROUP BY a→ 必须有INDEX(a)，INDEX(status, a)不行（最左前缀不匹配） - 多字段
GROUP BY a, b→ 必须是INDEX(a, b)，反过来建INDEX(b, a)基本没用 - 带
WHERE时，如WHERE c = 1 GROUP BY a, b→ 最优索引是INDEX(c, a, b)，把过滤字段放最左
GROUP BY和ORDER BY字段不一致，索引再好也白搭
这是线上最隐蔽的坑：即使GROUP BY a有索引，但你写GROUP BY a ORDER BY b，MySQL仍会走Using temporary。因为分组结果要按b重排，而b不在索引里，也没法复用分组过程中的有序性。
关键规则：ORDER BY字段必须是GROUP BY字段的**最左前缀且顺序严格一致**。比如GROUP BY a, b ORDER BY a DESC, b ASC可能跳过临时表；但GROUP BY a ORDER BY b一定不行。
- 业务真要按不同字段排序？优先考虑应用层排序，别让MySQL扛
- 实在要数据库排序，且
GROUP BY字段固定，可建覆盖索引+强制ORDER BY与之对齐，例如INDEX(a, b)配合GROUP BY a ORDER BY a, b -
SELECT DISTINCT a, b FROM t ORDER BY c这种——c和分组字段无关，临时表无法绕过
tmp_table_size和max_heap_table_size设不对，临时表秒落盘
Using temporary本身不是错误，但一旦临时表写到磁盘（Created_tmp_disk_tables飙升），性能就断崖下跌。真正决定它是否落盘的，是tmp_table_size和max_heap_table_size中**较小的那个值**。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
这两个值必须同步调整，否则改一个等于白改。默认值通常太小（比如16MB），几万行聚合就容易撑爆内存临时表。
- 查当前值：
SHOW VARIABLES LIKE 'tmp_table_size'和SHOW VARIABLES LIKE 'max_heap_table_size' - 临时调大（仅对新连接生效）：
SET SESSION tmp_table_size = 67108864;SET SESSION max_heap_table_size = 67108864（64MB） - 生产环境建议设为64M–256M，但务必监控
Created_tmp_tables / Created_tmp_disk_tables比值，理想应低于5% - 注意：
sort_buffer_size对GROUP BY完全无效，它只影响ORDER BY的排序缓冲
复杂表达式或函数会让索引失效，临时表绕不开
一旦GROUP BY里出现函数或计算，比如GROUP BY YEAR(create_time)、GROUP BY CONCAT(first_name, ' ', last_name)，即使原字段有索引，MySQL也无法直接利用，只能走临时表。
这类场景很难靠索引解决，得从查询逻辑入手：
- 能提前物化就物化：比如加个生成列
create_time_year INT AS (YEAR(create_time)) STORED，再给它建索引 - 避免在
GROUP BY中用COUNT(DISTINCT x)，尤其x没索引时，开销极大 - 子查询中含
GROUP BY且外层又JOIN或ORDER BY？大概率触发嵌套临时表，比单层更难优化
临时表不是洪水猛兽，但它的存在意味着MySQL放弃了流水线执行。真正棘手的从来不是“能不能加索引”，而是“加了索引，业务逻辑是否允许你按索引顺序组织查询”。
