Using temporary 表示 MySQL 需创建临时表处理中间结果，导致性能风险；常见于 GROUP BY 与 ORDER BY 字段不一致、DISTINCT 多表连接等场景，易引发磁盘 I/O 和内存开销。
为什么 EXPLAIN 显示 Using temporary 就代表性能风险
因为 MySQL 在执行查询时，不得不把中间结果写入磁盘临时表（或内存临时表），这会打断流水线执行、增加 I/O 和内存开销。尤其当数据量稍大（比如几万行以上）或并发一高，tmp_table_size 或 max_heap_table_size 不够用时，临时表会立刻落地到磁盘，性能断崖式下跌。
- 常见触发场景：
GROUP BY和ORDER BY字段不一致、含DISTINCT的多表连接、子查询中无主键/索引的聚合 - 注意：即使
EXPLAIN里没写Using filesort，只要出现Using temporary，就说明优化器放弃了“流式处理”，开始攒数据了 - 不是所有
Using temporary都能消除——比如SELECT DISTINCT a, b FROM t ORDER BY c，a,b和c无关，MySQL 必须先去重再排序，临时表无法绕过
GROUP BY 和 ORDER BY 字段不匹配是最大诱因
这是线上最常被忽视的根源。MySQL 要求：如果想避免临时表，GROUP BY 的字段必须是 ORDER BY 字段的**最左前缀**，且顺序严格一致。
- 错例：
SELECT a, COUNT(*) FROM t GROUP BY a ORDER BY b→ 必走临时表（a和b无关） - 对例：
SELECT a, COUNT(*) FROM t GROUP BY a ORDER BY a→ 可能跳过临时表（取决于索引） - 更优：
SELECT a, COUNT(*) FROM t GROUP BY a ORDER BY a DESC，同时建联合索引INDEX(a)或INDEX(a) USING BTREE（注意：哈希索引不支持排序） - 如果业务真要按不同字段排序，优先考虑应用层排序，而不是硬扛数据库临时表
如何用 SHOW PROFILE 和 tmpdir 日志确认临时表开销
光看 EXPLAIN 不够，得验证它到底有没有写磁盘、花了多少时间。
- 先开分析：
SET profiling = 1，然后执行目标 SQL，再查SHOW PROFILES找 Query_ID，最后SHOW PROFILE FOR QUERY N - 重点看
Copying to tmp table和Copying to tmp table on disk这两行耗时；后者出现即表示内存不足、已落盘 - 检查当前临时表路径：
SELECT @@tmpdir，并确认该目录所在磁盘空间和 IO 负载（很多 DBA 忘了清空/tmp下残留的#sql_*文件） - 临时调大限制（仅调试）：
SET SESSION tmp_table_size = 268435456（256MB），但别长期设太高，容易挤占其他连接内存
哪些索引能真正抑制 Using temporary
不是加了索引就有用。关键看索引是否覆盖 GROUP BY/ORDER BY 字段，且字段顺序与查询逻辑对齐。
- 单字段聚合：
GROUP BY user_id→ 索引INDEX(user_id)有效；INDEX(status, user_id)无效（最左前缀不匹配） - 多字段聚合：
GROUP BY region, city→ 必须建INDEX(region, city)，反过来不行 - 带 WHERE 条件时：
WHERE status = 1 GROUP BY user_id→INDEX(status, user_id)是最优解，既过滤又分组 - 注意：全文索引、空间索引、前缀索引（如
INDEX(name(10))）都不能用于分组/排序加速
临时表不是 bug，是 MySQL 在约束下做的权衡。真正难的是判断——这个临时表，到底是设计使然，还是索引没对、语义写歪了。盯着 EXPLAIN 里的 key_len 和 Extra 对着索引定义一行行比，比调参数管用得多。
