group by触发磁盘临时表的直接原因是中间结果超出tmp_table_size与max_heap_table_size的较小值，或含blob/text字段；根本在于索引未按group by字段顺序严格覆盖，导致无法流式扫描而必须攒数据分组。
GROUP BY 触发磁盘临时表的直接原因
MySQL 执行 GROUP BY 时，一旦中间分组结果超出内存阈值，就会把临时表从内存（MEMORY 引擎）退化为磁盘（MyISAM 或 InnoDB）临时表——这不是“可能”，而是确定行为。根本判断依据是：tmp_table_size 和 max_heap_table_size 中的较小值。哪怕只超 1 字节，整个临时表立刻落地。
- 查当前阈值：
SELECT @@tmp_table_size, @@max_heap_table_size; - 字段含
BLOB/TEXT或定义过宽（如VARCHAR(2000)），也会强制落盘，和数据量无关 -
sort_buffer_size对此无影响——它只管排序，不管临时表
为什么索引没用上，导致必须建临时表
不是没建索引，而是索引没被“正确覆盖”。GROUP BY 要跳过临时表，得满足两个硬条件：数据在磁盘上物理有序 + 查询路径能流式扫描。一旦破环，MySQL 只能攒数据再分组。
- 联合索引顺序必须严格匹配
GROUP BY字段顺序，例如GROUP BY region, city需要INDEX(region, city)，INDEX(city, region)无效 - WHERE 条件含范围查询（如
created_at > '2025-01-01'）时，该字段必须放在联合索引最右，否则左侧字段无法用于有序分组 - 隐式类型转换（如
user_id = '123'对比BIGINT）会让整个索引失效，执行计划里key可能显示用了索引，但Extra仍出现Using temporary
EXPLAIN 里看到 Using temporary 就已经晚了
Using temporary 出现在 EXPLAIN 的 Extra 列，说明优化器已放弃流式处理，开始攒中间结果。此时性能拐点已到，再调参只是延缓崩溃，不是修复。
- 用
SHOW PROFILE FOR QUERY N确认是否真写磁盘：重点看Copying to tmp table on disk这一行耗时 - 检查
@@tmpdir路径所在磁盘空间，/tmp下残留的#sql_*文件不清理，磁盘满得毫无征兆 -
ORDER BY NULL只能消除Using filesort，对Using temporary无效——分组逻辑本身仍低效
真正有效的三件事，而不是调参
调大 tmp_table_size 和 max_heap_table_size 是兜底手段，不能解决分组逻辑失控问题。线上高频慢查询，90% 的根因是访问路径设计错位。
- 删掉所有单列索引，显式建覆盖索引：比如
SELECT user_id, COUNT(*) FROM orders WHERE status = 1 GROUP BY user_id，必须建INDEX(status, user_id) - 避免
SELECT *：只取GROUP BY字段和聚合字段，减小每行体积，延缓落盘临界点 - 拆分大时间窗口：用
WHERE created_at BETWEEN '2025-01-01' AND '2025-01-31'分月聚合，再UNION ALL，比单查一年快一个数量级
user_id 加了单列索引，只要查询里带 WHERE status = 1，这个单列索引就大概率不会被用于分组——MySQL 不会自动拼接两个单列索引，必须显式建联合索引覆盖完整链路。
