Using temporary不是错误，而是MySQL因索引无法支持有序分组而创建内部临时表的合理fallback；真正需解决的是索引缺失、字段顺序错配或分组键基数失控等问题。
直接说结论：Using temporary 不是必须消灭的“错误”，而是 MySQL 在无法用索引顺序完成分组时的合理 fallback；真正要干掉的是它背后暴露的索引缺失、字段错配或基数失控问题。
为什么 GROUP BY 会触发 Using temporary
MySQL 只有在能按 GROUP BY 字段「自然有序扫描」时，才可能跳过临时表。一旦分组字段顺序和索引顺序不一致、WHERE 条件用了范围查询（如 group_id BETWEEN 1 AND 10）、或者 SELECT 中带了非聚合且未覆盖的列，优化器就无法流式累加，只能先捞数据进临时表再归并。
-
EXPLAIN里出现Using temporary，往往同时伴随Using filesort—— 这说明连排序都保不住，更别说免临时表了 - 即使有索引，如果
GROUP BY a, b，但索引是(b, a)或(a)单列，也不满足最左前缀匹配，照样建临时表 - 使用
SELECT *或SELECT a, b, MAX(c)却没把a, b全包含在索引左侧，会导致回表或放弃索引，间接触发临时表
建什么索引才能让 GROUP BY 跳过临时表
核心是让索引键顺序与 GROUP BY 字段顺序严格一致，并尽可能覆盖 WHERE 和 SELECT 需求。不是“加个索引就行”，而是“加对位置、对顺序、对宽度”的索引。
- 单字段分组：如
GROUP BY dept_id，建INDEX idx_dept (dept_id)就够；但如果还带WHERE status = 'active'，优先建(status, dept_id)—— 把等值条件放前面 - 多字段分组：如
GROUP BY user_id, DATE(created_at)，不能只建(user_id)；得建函数索引（MySQL 8.0+）INDEX idx_uid_date ((user_id, DATE(created_at)))，或冗余生成列 + 普通索引 - 带 ORDER BY 的场景：若写成
GROUP BY a, b ORDER BY a, b，一个(a, b)索引可同时服务两者；但若ORDER BY a DESC, b ASC，MySQL 5.7 不支持混合方向索引，必然退化为Using filesort
tmp_table_size 调大就能避免磁盘临时表吗
能缓解，但治标不治本。内存临时表转磁盘临时表的临界点由 tmp_table_size 和 max_heap_table_size 二者最小值决定，默认都是 16MB。盲目调大可能挤占其他内存资源，且无法解决根本的 I/O 和 CPU 压力。
- 查当前设置：
SHOW VARIABLES LIKE 'tmp_table_size';和SHOW VARIABLES LIKE 'max_heap_table_size'; - 临时生效（会话级）：
SET SESSION tmp_table_size = 64 * 1024 * 1024;，但仅对当前连接有效 - 真正该做的：用
EXPLAIN FORMAT=JSON查看used_memory和estimated_row_count，判断是否真因数据量大而溢出，还是因分组键基数太高（比如按毫秒时间戳分组），此时应改用预聚合或降精度（DATE(created_at)）
SQL_BIG_RESULT 真的有用吗
有用，但只在明确知道结果集巨大、且愿意牺牲内存换稳定时才用。它会绕过内存临时表阶段，直接用磁盘临时表 + 数组结构做分组，避免反复扩容拷贝，适合千万级分组后仍需全量返回的报表类查询。
- 语法：
SELECT SQL_BIG_RESULT user_id, COUNT(*) FROM logs GROUP BY user_id; - 副作用：失去松散索引扫描（Loose Index Scan）机会，哪怕有合适索引也会强制走 Tight Index Scan + 临时表
- 典型误用：把它当成“加速 GROUP BY 的万能开关”——实际上，加了它反而比不加慢，因为放弃了所有索引优化路径
最容易被忽略的一点：GROUP BY 的性能瓶颈往往不在分组本身，而在前面的数据拉取。如果 WHERE 条件没走索引，先扫几百万行再分组，再好的分组算法也救不回来。盯紧 EXPLAIN 的 type 和 rows，比死磕 Using temporary 更有效。
