查询时临时表影响性能吗
做网站开发时，数据库查询是家常便饭。有时候为了处理复杂逻辑，我们会用到临时表。比如统计某个时间段内用户的下单行为，先筛选再聚合，中间结果存到临时表里接着用。听起来挺方便，但问题来了：这样真的不会拖慢系统吗？
答案是：可能会影响，关键看怎么用。
临时表不是免费的
每次创建临时表，MySQL 都要在内存或磁盘上分配空间。如果数据量小，比如几千行，通常走的是内存引擎（如 Memory 或 InnoDB 的内存页），速度还行。但一旦超出内存限制，就会写入磁盘，这时候 I/O 开销就上来了，查得慢不说，还可能把服务器资源占满。
举个例子，你在后台跑一个报表功能，用户一点击就生成一堆临时表，每张表几万条数据。这时候如果有多个用户同时操作，数据库连接数飙升，磁盘读写频繁，整个网站响应都会变卡。
哪些情况容易出问题
嵌套子查询被优化器转成临时表的情况很常见。比如下面这种写法：
SELECT * FROM (
SELECT user_id, COUNT(*) AS cnt FROM orders WHERE create_time > '2024-01-01'
GROUP BY user_id
) AS tmp WHERE cnt > 5;</code></pre><p>这个子查询的结果会被存进临时表。如果 orders 表很大，分组前没走索引，那这一步就很吃资源。更糟的是，临时表没有索引（除非手动加），外层再过滤时只能全表扫。</p><h3>能不用就不用，能优化就优化</h3><p>很多时候临时表并不是唯一解。比如上面的例子，完全可以改写成带 HAVING 的单层查询：</p><pre><code>SELECT user_id, COUNT(*) AS cnt FROM orders
WHERE create_time > '2024-01-01'
GROUP BY user_id HAVING cnt > 5;这样避免了临时表，还能利用索引，执行效率更高。
另外，如果确实要用临时表，记得给它加上必要的索引。MySQL 8.0 以后在某些场景下会自动为临时表创建索引，但别完全依赖它。手动控制更稳妥。
监控和排查也很重要
当你发现某个页面突然变慢，可以打开慢查询日志看看有没有 Using temporary 的标记。用 EXPLAIN 分析 SQL 执行计划时，如果 Extra 列出现 Using temporary，基本就能确定用了临时表。这时候就得回头看看是不是查询写得太绕，或者缺少合适的索引。
临时表本身不是洪水猛兽，它在分步处理、避免重复计算上有优势。但在高并发的网站环境下，每一次不必要的临时表操作都可能是压垮性能的一根稻草。合理使用，才能既解决问题又不拖后腿。