出现Using temporary说明MySQL正用磁盘临时表分组，导致I/O激增、查询变慢；应通过EXPLAIN确认问题，优化索引（联合索引需匹配GROUP BY顺序）、避免高基数字段直接分组、优先WHERE过滤、添加ORDER BY NULL等。
EXPLAIN里出现Using temporary就该动手了
只要执行计划的Extra列里有Using temporary或Using filesort，基本等于MySQL正在用磁盘临时表做分组——I/O一上来，查询就从毫秒跳到秒级。这不是警告，是确诊书。
实操建议：
- 先跑
EXPLAIN FORMAT=TRADITIONAL SELECT ... GROUP BY ...确认问题存在，别凭感觉建索引 - 检查
type字段：如果是ALL或index（而非ref/range），说明没走有效索引 - 核对
key_len：比如字段是VARCHAR(255)但只用了前10个字节，key_len却显示765，说明索引定义和实际查询不匹配 -
Extra里没有Using where？那WHERE条件很可能没进索引，过滤被挪到了分组后
GROUP BY字段顺序必须和联合索引完全一致
单列索引对多字段分组几乎无效。真正起效的是最左前缀匹配的联合索引，且字段顺序必须和GROUP BY子句完全一致。
实操建议：
- 例如
GROUP BY user_id, status, region→ 建INDEX idx_group (user_id, status, region) - 如果还有
WHERE status = 'active'，优先把高选择性字段放前面：INDEX idx_where_group (status, user_id, region) - 若
SELECT还包含AVG(amount)和MAX(created_at)，可扩展为(status, user_id, region, amount, created_at)，形成覆盖索引，避免回表 - 切记：
GROUP BY DATE(created_at)会让整个索引失效——改用冗余created_date字段加索引，或用范围条件替代
WHERE过滤必须比GROUP BY更早发生
HAVING是分组后过滤，开销远高于WHERE。报表类查询中，90%的慢，是因为本该在扫描阶段剔除的数据，被拖到了聚合之后才筛。
实操建议：
- 错误写法：
SELECT dept, AVG(salary) FROM emp GROUP BY dept HAVING AVG(salary) > 10000（先分组全部部门，再筛） - 优化思路：若业务允许，先
WHERE salary > 8000再分组；或结合分区表按时间/地域预切片 - 高频统计场景（如日报），宁可用定时任务写预聚合表，也别让每次查询都重算
-
ORDER BY NULL要显式加上——省掉默认隐式排序开销，尤其当结果不需要排序时
高基数字段直接GROUP BY极易触发磁盘临时表
像email、order_no、ip这类字段，值几乎唯一，分组桶数爆炸，内存哈希表撑不住，必然落盘。这不是参数能调出来的，是设计层面的问题。
实操建议：
- 先降维：
GROUP BY SUBSTRING_INDEX(email, '@', -1)（提取域名）、GROUP BY INET_ATON(ip) >> 24（转C段） - 用哈希截断：
GROUP BY MD5(order_no) % 100（仅限近似统计场景） - 大表+高基数分组，考虑换引擎：ClickHouse或StarRocks原生支持高性能列存聚合
-
tmp_table_size和max_heap_table_size可调到64M–256M，但只是缓冲，不能掩盖逻辑缺陷
复杂点往往藏在“WHERE和GROUP BY字段不重叠”这种看似合理的组合里——比如WHERE created_at > '2024-01-01'但GROUP BY user_id, product_id，索引很难同时兼顾过滤与分组顺序，这时就得靠冗余字段或物化视图兜底。
