在MySQL数据库的实际使用中，复杂查询往往涉及多张表的关联、多层嵌套的子查询，或者需要多次复用同一部分中间计算结果，这类场景如果直接编写单条复杂SQL，不仅可读性差，还容易出现执行效率低下的问题。MySQL临时表就是专门用来解决这类问题的工具，它可以临时存储查询过程中的中间结果，让复杂逻辑拆分得更清晰，也能避免重复计算。
MySQL临时表的核心特性
MySQL临时表是会话级别的临时对象，和普通的用户表有明显区别，核心特性主要有以下几点：
- 生命周期与会话绑定：临时表只在创建它的数据库会话中存在，会话断开后，临时表会自动被删除，不需要手动清理。
- 可见性限制：临时表只对创建它的会话可见，其他数据库会话无法查询到该临时表，也不会出现表名冲突的问题。
- 存储引擎可选：创建临时表时可以指定存储引擎，默认使用服务器的默认存储引擎，也可以使用MEMORY引擎提升读写速度，或者使用InnoDB引擎支持事务。
- 支持索引创建：临时表和普通表一样可以创建索引，针对中间数据的查询场景创建合适的索引，能进一步提升临时表的查询效率。
临时表的创建方式
MySQL中创建临时表主要有两种方式，分别是手动显式创建和查询时隐式创建。
手动显式创建临时表
手动创建临时表的语法和普通表类似，只需要在CREATE后面加上TEMPORARY关键字即可，语法如下：
-- 创建临时表，指定存储引擎为MEMORY，适合小量中间数据快速读写
CREATE TEMPORARY TABLE tmp_user_order_stats (
user_id INT NOT NULL,
order_count INT DEFAULT 0,
total_amount DECIMAL(10,2) DEFAULT 0.00,
INDEX idx_user_id (user_id)
) ENGINE=MEMORY;
-- 向临时表插入数据，统计每个用户的订单数量和总金额
INSERT INTO tmp_user_order_stats (user_id, order_count, total_amount)
SELECT user_id, COUNT(order_id), SUM(order_amount)
FROM order_info
WHERE order_status = 1
GROUP BY user_id;
查询时隐式创建临时表
当执行某些复杂查询时，MySQL优化器会自动创建内部临时表来存储中间结果，比如使用UNION、GROUP BY、ORDER BY且无法使用索引的场景，或者子查询的结果集需要复用的情况。不过隐式创建的临时表由MySQL自动管理，开发者无法直接操作，如果需要优化这类场景，可以手动创建临时表替代隐式临时表，提升可控性。
用临时表处理复杂查询的场景示例
下面通过一个实际的业务场景说明临时表的应用方法，假设需要查询近30天订单金额排名前100的用户，同时统计这些用户的历史总订单金额和近30天的订单占比。
如果直接编写单条SQL，需要同时关联订单表做两次聚合计算，效率较低，拆分后用临时表处理会更清晰：
-- 第一步：创建临时表存储近30天每个用户的订单统计
CREATE TEMPORARY TABLE tmp_recent_order (
user_id INT NOT NULL,
recent_order_count INT,
recent_total_amount DECIMAL(10,2),
INDEX idx_user_id (user_id)
) ENGINE=InnoDB;
-- 插入近30天的订单统计数据
INSERT INTO tmp_recent_order (user_id, recent_order_count, recent_total_amount)
SELECT user_id, COUNT(order_id), SUM(order_amount)
FROM order_info
WHERE order_create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
AND order_status = 1
GROUP BY user_id;
-- 第二步：关联临时表和全量订单统计，获取最终结果
SELECT
u.user_id,
u.user_name,
tmp.recent_order_count,
tmp.recent_total_amount,
all_order.total_order_count,
all_order.total_amount,
-- 计算近30天订单金额占比
ROUND(tmp.recent_total_amount / all_order.total_amount * 100, 2) AS recent_amount_rate
FROM tmp_recent_order tmp
JOIN user_info u ON tmp.user_id = u.user_id
JOIN (
-- 子查询统计用户全量订单数据
SELECT user_id, COUNT(order_id) AS total_order_count, SUM(order_amount) AS total_amount
FROM order_info
WHERE order_status = 1
GROUP BY user_id
) all_order ON tmp.user_id = all_order.user_id
ORDER BY tmp.recent_total_amount DESC
LIMIT 100;
这个示例中，临时表tmp_recent_order存储了近30天的订单中间结果，避免了重复扫描近30天的订单数据，同时让查询逻辑拆分得更清晰，可读性也更强。
临时表使用的注意事项
虽然临时表能优化复杂查询，但使用时也需要注意一些问题，避免带来额外的性能问题：
- 临时表的数据量不宜过大：如果临时表存储的数据量超过内存限制，MEMORY引擎的临时表会转换为磁盘存储，性能会下降，此时可以选择InnoDB引擎，或者优化查询逻辑减少中间数据量。
- 避免临时表名和已有普通表重名：如果当前会话下临时表名和已有的普通表名相同，那么在该会话中会优先访问临时表，普通表会被隐藏，直到临时表被删除，容易造成逻辑混淆。
- 及时清理不需要的临时表：虽然会话断开后临时表会自动删除，但如果会话长时间存在，不需要的临时表会占用内存或磁盘空间，可以在使用完成后手动执行DROP TEMPORARY TABLE语句删除。
- 临时表不支持外键约束：如果业务需要外键关联，临时表无法满足，需要选择其他方案处理中间数据。
临时表和普通表、派生表的区别
很多开发者会混淆临时表、普通表和派生表的概念，这里通过表格做简单对比：
| 对比项 | 普通表 | 临时表 | 派生表（子查询生成的表） |
|---|---|---|---|
| 生命周期 | 永久存在，除非手动删除 | 会话级别，会话断开自动删除 | 仅在当前查询执行过程中存在 |
| 可见性 | 所有有权限的会话可见 | 仅创建会话可见 | 仅当前查询可见 |
| 是否支持索引 | 支持 | 支持 | 不支持 |
| 是否可复用 | 可多次复用 | 同一会话内可多次复用 | 不可复用，每次查询需要重新生成 |
通过对比可以看出，临时表适合需要多次复用中间结果、且中间结果不需要永久保存的场景，比派生表更灵活，比普通表更轻量，是处理复杂查询中间数据的合适选择。