在日常使用数据库的过程中，很多人会遇到查询变慢的问题。尤其是在执行复杂 SQL 语句时，数据库可能会自动创建临时表来辅助运算。这时候就会有人问：查询时用到的临时表，真的会影响性能吗？答案是——有可能，而且影响还不小。
临时表是怎么来的？
当你执行一条包含 GROUP BY、ORDER BY、UNION 或子查询的 SQL 语句时，MySQL 等数据库为了处理中间结果，可能会在内存或磁盘上创建一个临时表。比如下面这条查询：
SELECT user_id, COUNT(*) FROM logs GROUP BY user_id ORDER BY COUNT(*) DESC;如果数据量大，又没有合适的索引，数据库很可能先建立临时表来分组统计，再排序输出。这个过程看似透明，实则消耗资源。
内存 vs 磁盘：差别巨大
临时表一开始通常放在内存里，使用 MEMORY 引擎，速度很快。但一旦数据超过一定大小（比如 tmp_table_size 或 max_heap_table_size 的限制），它就会被转成磁盘临时表，这时性能就会明显下降。
磁盘 I/O 比内存访问慢几十甚至上百倍。想象一下，原本几毫秒能查完的数据，因为临时表“溢出”到硬盘，变成几百毫秒甚至更久，用户体验立马打折扣。
什么情况下容易出问题？
常见的“高危”场景包括：多表 JOIN 后做分组、对没有索引的字段排序、使用 SELECT * 查询大量字段并去重。这些操作都可能触发大临时表的生成。
举个例子，后台有个报表功能，用户点击后要查一个月的日志数据并按设备类型汇总。如果没加索引，系统每次都要扫描几十万行记录，生成一个几 MB 的临时表，时间自然拖得老长。
怎么判断是不是临时表惹的祸？
可以用 EXPLAIN 分析 SQL 执行计划，看 Extra 字段有没有出现 Using temporary。如果有，说明用了临时表。
EXPLAIN SELECT device, COUNT(*) FROM logs GROUP BY device;另外，通过查看状态变量也能发现端倪：
SHOW STATUS LIKE 'Created_tmp_tables';
SHOW STATUS LIKE 'Created_tmp_disk_tables';如果磁盘临时表的数量一直在涨，就得警惕了。
优化思路其实很直接
第一，给经常用于分组、排序的字段加索引。比如上面的例子，在 device 字段上建索引，很多时候就能避免临时表。
第二，控制查询的数据量。不要动不动就查全表，尽量加上时间范围等过滤条件。
第三，适当调大 tmp_table_size 和 max_heap_table_size，让临时表能在内存中完成操作。但别设太大，否则有内存风险。
第四，复杂查询可以拆解，或者把中间结果存到真实表里，手动管理，比依赖自动临时表更可控。
不是所有临时表都该消灭
有些场景下，临时表是不可避免的，也是合理的。关键是要知道它什么时候出现、为什么会出来，能不能优化掉。盲目接受“慢查询”，不如花几分钟看看执行计划，说不定改个索引就快了十倍。