GroupBy 产生临时表是因为缺乏合适索引时需先写入内存或磁盘临时表再排序聚合；是否落盘取决于 tmp_table_size 和 max_heap_table_size 的较小值；sort_buffer_size 仅影响排序操作，与临时表无关。
GroupBy 为什么会产生临时表
MySQL 在执行 GROUP BY 时，如果无法利用索引完成分组（比如没有合适的联合索引、或用了函数/表达式），就会被迫把数据先写入内存临时表（MEMORY 引擎）或磁盘临时表（MyISAM 或 InnoDB），再排序+聚合。一旦数据量超过 tmp_table_size 和 max_heap_table_size 中的较小值，就会落盘，性能断崖式下降。
SortBufferSize 和 GroupBy 没有直接关系
sort_buffer_size 是为每个**排序操作**单独分配的内存缓冲区，只在需要 ORDER BY 或某些 GROUP BY（特别是配合 ORDER BY 且无索引覆盖时）才会用上。它不控制临时表大小，也不影响 GROUP BY 是否走临时表——那是 tmp_table_size 和 max_heap_table_size 的职责。
-
sort_buffer_size过大反而浪费内存，且不会复用，每个需要排序的连接都独占一份 - 调高它对纯
GROUP BY（无ORDER BY、有合适索引）完全无效 - 真正决定“是否用临时表”和“临时表放内存还是磁盘”的是
tmp_table_size和max_heap_table_size
优化 GroupBy 临时表的实操路径
与其盲目调 sort_buffer_size，不如按优先级做这几件事：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 加索引：确保
GROUP BY字段（及WHERE条件字段）有前缀匹配的联合索引，例如SELECT COUNT(*) FROM t WHERE status=1 GROUP BY category, type应建INDEX(status, category, type) - 检查执行计划：用
EXPLAIN FORMAT=TRADITIONAL看Extra列是否含Using temporary; Using filesort，这是关键信号 - 调大临时表上限：若确认必须走临时表，同步增大
tmp_table_size和max_heap_table_size（二者需一致，否则以小的为准），单位是字节，例如设为67108864（64MB） - 避免 SELECT *：只查
GROUP BY字段和聚合字段，减少临时表行宽，延缓落盘
什么时候才该动 sort_buffer_size
仅当 EXPLAIN 显示 Using filesort 且你确认排序是瓶颈（比如慢日志里 Sorting result 耗时占比高），再考虑微调 sort_buffer_size。注意：
- 它默认是 256KB，一般够用；超过 4MB 很少有必要
- 线上建议从 512KB 或 1MB 开始试，观察
SHOW STATUS LIKE 'Sort_merge_passes'是否下降（越少越好） - 不能替代索引，也不能解决
Using temporary—— 那是另一回事
临时表逻辑比想象中复杂，GROUP BY 的执行路径依赖索引结构、字段类型、NULL 处理、SQL 模式（如 ONLY_FULL_GROUP_BY），光调一个 buffer 很难见效。
