在日常的数据库运维中，经常能碰到一些执行缓慢的SQL查询。排查过程中，很多人会发现执行计划里出现了“Using temporary”这样的提示，这意味着查询正在使用临时表。这时候就会有个疑问：查询时临时表到底会不会影响性能？
临时表是怎么产生的
MySQL在处理某些复杂查询时，无法直接通过索引返回结果，就需要创建一个中间表来暂存数据。比如常见的GROUP BY、ORDER BY与JOIN混用，且涉及的字段没有合适索引时，就会触发临时表的创建。
举个例子，有张订单表order_list，想按用户分组统计金额，并按总金额排序：
SELECT user_id, SUM(amount) FROM order_list GROUP BY user_id ORDER BY SUM(amount);如果user_id和amount都没有有效索引支持，MySQL很可能先建立一个临时表存放分组结果，再对这个临时表进行排序。这个过程就增加了额外开销。
内存还是磁盘？这才是关键
临时表本身不是洪水猛兽，真正影响性能的是它被创建在哪儿。MySQL会优先把临时表放在内存（使用MEMORY引擎），访问速度非常快。但一旦数据量超过某个阈值（由tmp_table_size和max_heap_table_size控制），就会转成磁盘临时表（MyISAM或InnoDB），这时IO开销明显上升。
比如一个报表查询，临时表从内存落到磁盘，原本1秒能跑完的SQL突然变成10秒以上，这种情况在实际项目中并不少见。
怎么判断有没有问题
可以通过查看状态变量来确认是否频繁使用了磁盘临时表：
SHOW STATUS LIKE 'Created_tmp%';关注两个值：Created_tmp_tables 是总共创建的临时表数量，Created_tmp_disk_tables 是其中写入磁盘的数量。如果后者占比高，就得警惕了。
优化方向其实很直接
最有效的办法是减少临时表的使用。给GROUP BY、ORDER BY涉及的字段加上联合索引，能让MySQL直接利用索引顺序输出结果，避免排序和临时表。
比如上面那个查询，如果在(user_id, amount)上建了索引，很可能就不需要临时表了。
另外也可以适当调大tmp_table_size和max_heap_table_size，让更大的临时结果集留在内存中。但不能无限制调大，毕竟每个连接都可能创建临时表，内存压力会累积。
有时候业务逻辑绕一点反而更高效。比如先把分组结果存到一张小表里，再单独排序，比一次性大查询更可控。
临时表不是不能用，关键是得知道它什么时候出现、在哪运行、花了多少资源。监控+索引优化+合理配置，才能让它不拖慢系统。