group by触发磁盘临时表是因为中间结果超出tmp_table_size与max_heap_table_size较小值，被迫落盘；根本原因是索引未覆盖where、group by及select字段，导致无法有序扫描，必须建临时表分组并排序。

为什么GROUP BY会触发磁盘临时表？

MySQL（尤其是5.7及8.0默认配置下）在执行 GROUP BY 时，若无法在内存中完成分组（比如结果集大、sort_buffer_size 小、或含大字段如 TEXT/VARCHAR(5000)），就会把中间结果写入磁盘临时表——表现为 Created_tmp_disk_tables 计数上升，同时慢日志里可能出现 Using temporary; Using filesort。

关键判断依据不是“有没有 GROUP BY”，而是 EXPLAIN 输出中的 Extra 字段是否含 Using temporary，以及实际执行时是否落到磁盘。

怎么让 GROUP BY 尽量走内存？

• 确保分组字段有合适索引：如果 GROUP BY a, b，优先建联合索引 INDEX(a, b)（顺序不能错），避免排序+临时表双开销
• 减少 SELECT 中的非分组字段：不要写 SELECT <em>, COUNT(</em>) FROM t GROUP BY x，只选真正需要的列，尤其避开未加在 GROUP BY 中的长文本字段
• 调大内存相关参数（仅限专用数据库实例）：tmp_table_size 和 max_heap_table_size 必须同时调大且值一致，否则以较小者为准；例如设为 256M
• 避免隐式类型转换：比如 GROUP BY user_id 但 user_id 是 VARCHAR 而条件里传了数字，会导致索引失效，继而无法利用索引做松散扫描（Loose Scan），被迫建临时表

当必须用磁盘临时表时，如何降低影响？

• 把 tmpdir 指向 SSD 路径（如 /mnt/ssd/mysql-tmp），并确保该分区不与 datadir 共用物理盘
• 在业务低峰期执行大分组任务，避免和主库写入争 I/O
• 对超大数据集，改用应用层分批处理：先 SELECT DISTINCT group_key FROM t WHERE ... 拿到分组键，再循环按 key 单独聚合，绕过单次大临时表
• 如果是报表类场景，提前物化结果到汇总表（如每天凌晨跑 INSERT INTO report_daily SELECT ..., COUNT(*) ... GROUP BY ...），查询直接读汇总表

容易被忽略的坑：ORDER BY + GROUP BY 的组合

MySQL 5.7 默认开启 sql_mode=ONLY_FULL_GROUP_BY，但即使通过了语法检查，如果写 GROUP BY x ORDER BY y 且 y 不在分组字段或聚合函数中，仍可能放弃索引、强制走临时表排序。更糟的是，8.0 中若 ORDER BY 字段无索引，即便 GROUP BY 本身能走索引，整个执行计划仍可能退化为 Using temporary; Using filesort。

coding-agent

一款AI开发辅助工具，主要用于通过后台进程将编码任务委托给 Codex、Claude Code 或 Pi 智能体。适用场景：（1）构建或创建新功能/应用，（2）审查 PR，适合需要提升相关任务效率的用户。

下载

所以，真要排序，要么确保 ORDER BY 字段包含在 GROUP BY 中（如 GROUP BY x, y ORDER BY y），要么给 ORDER BY 单独建索引，或者干脆去掉 ORDER BY —— 排序本就不该由 GROUP BY 承担。

临时表问题从来不是孤立的，它暴露的是索引设计、字段选择、参数配置三者的耦合缺陷。盯着 tmp_table_size 硬调，不如先看 EXPLAIN FORMAT=JSON 里 used_memory 和 used_disk 的真实值。