Using temporary表示MySQL因索引未覆盖WHERE、GROUP BY及SELECT非聚合字段而被迫建临时表，优化首选覆盖索引（如INDEX(status, category)），而非调参；sort_buffer_size对GROUP BY无效，tmp_table_size与max_heap_table_size需同步调大防落盘。
EXPLAIN 出现 Using temporary 怎么办
看到 Using temporary 就说明 MySQL 正在建临时表做分组，这是性能拐点，不是数据量大才出问题，而是索引没对上。它常和 Using filesort 一起出现，意味着既落盘又排序。
真正该做的不是调内存参数，而是检查索引是否覆盖了三个环节：WHERE 条件、GROUP BY 字段、SELECT 中的非聚合字段。比如查询：
SELECT category, COUNT(*) FROM product WHERE status = 1 GROUP BY category;
必须建 INDEX(status, category)，而不是 INDEX(category) 或 INDEX(status)。否则优化器无法“顺着索引读，相同 category 值天然连续”，只能捞全量数据进临时表再归并。
- 索引列顺序必须严格匹配 GROUP BY 字段顺序（
GROUP BY a, b→ 索引要(a, b)，不能是(b, a)） - WHERE 中的等值条件（
=、IN）可前置，范围条件（>、BETWEEN）会中断最左前缀，让后续字段失效 - 如果 SELECT 里有
MAX(price)，且 price 在索引中紧接在分组字段后（如(status, category, price)），才可能触发 Loose Index Scan；否则照样走临时表
为什么调 sort_buffer_size 没用
sort_buffer_size 只影响排序操作，和 GROUP BY 是否建临时表完全无关。它不控制临时表大小，也不决定 “用不用临时表”——那是 tmp_table_size 和 max_heap_table_size 的事。
常见误判场景：
- 你改了
sort_buffer_size，但 EXPLAIN 里仍有Using temporary：说明根本没走到排序那步，还在建表阶段 - 查询没写
ORDER BY，却看到Using filesort：可能是 ORM 自动加了，或客户端隐式要求排序，也可能是索引没覆盖 SELECT 字段导致回表后被迫排序 - 把
sort_buffer_size设到 8MB：每个连接独占一份，高并发下极易 OOM，而实际收益几乎为零
真要调它，只在 EXPLAIN 明确显示 Using filesort 且慢日志里 Sorting result 耗时占比高时，从 512KB 试起，观察 Sort_merge_passes 是否下降。
ORDER BY NULL 还要不要加
要，而且现在更关键。MySQL 5.7+ 已移除 GROUP BY 隐式排序语义，但优化器仍可能因“以为你要排序”而选错索引路径。加上 ORDER BY NULL 是明确指令：别排，省掉一次无谓判断。
写法必须紧接在 GROUP BY 后：
GROUP BY category ORDER BY NULL
注意：
- 不能写成
GROUP BY category, ORDER BY NULL（语法错误） - 如果后续带
LIMIT，MySQL 可能无法利用索引 early-termination，这时得权衡：要速度还是要分页语义 - 若业务真需要特定顺序（比如
ORDER BY category DESC），MySQL 8.0+ 可建降序索引INDEX(status, category DESC)；5.7 及以前只能接受Using filesort或改逻辑
临时表落盘了还能抢救吗
能，但属于兜底手段。当确认必须走临时表（比如 GROUP BY 带函数、或字段类型不支持索引扫描），就确保它别写磁盘：
- 同步调大
tmp_table_size和max_heap_table_size，设为相同值（比如67108864，即 64MB），否则以较小者为准 - 避免
SELECT *，只查 GROUP BY 字段和聚合字段，减小单行宽度，延缓达到阈值 - 慎用
SQL_BIG_RESULT提示：它会直接跳过内存临时表，强制走磁盘，除非你明确知道数据量极大且磁盘 I/O 更稳
最易被忽略的一点：临时表行为受 SQL_MODE 影响。如果开了 ONLY_FULL_GROUP_BY，而查询又写了非分组非聚合字段，MySQL 会先报错或退化处理，这比慢还麻烦——务必先校验 SQL 合法性，再谈优化。
