MySQL临时表是会话级私有表，只在当前连接中存在且断开即删；必须用CREATE TEMPORARY TABLE显式创建，支持主键索引和AS SELECT，但不支持外键分区等；同名普通表会被遮蔽，典型用于复杂查询拆解、ETL清洗和存储过程状态共享，但需警惕连接池复用、事务无关性及大数据量性能反模式。
MySQL临时表是会话级私有表，只在当前连接中存在，断开即删——它不是缓存，也不是全局中间件，而是一个“用完就扔”的本地数据容器。
CREATE TEMPORARY TABLE 是唯一创建方式
临时表不能通过 CREATE TABLE 加个注释或配置项变出来，必须显式写 CREATE TEMPORARY TABLE。漏掉 TEMPORARY 关键字，建出来的就是普通表，后续不会自动清理，容易堆积成隐患。
- 语法和普通表完全一致，支持主键、索引、
AS SELECT快速填充 - 不支持外键、分区、视图、触发器——这些约束在临时表上直接报错
- 存储引擎默认是
InnoDB（5.7+），但若字段含TEXT/BLOB或行太宽，可能退化为磁盘表，受tmp_table_size和max_heap_table_size限制 - 同名普通表会被遮蔽：执行
SELECT * FROM users时，如果当前会话存在temp_users，实际查的是临时表，不是原表
典型使用场景：复杂查询拆解与批量处理
临时表不是“能用就用”，而是当以下情况出现时才值得引入：
- 一个子查询被反复引用超过两次（比如在
JOIN、WHERE、HAVING中都出现），用临时表存一次比反复计算更稳 - 报表 SQL 嵌套过深，调试困难，把中间结果落表后可逐层
SELECT验证逻辑 - ETL 导入前需清洗校验：先
INSERT INTO temp_raw AS SELECT ...，再SELECT COUNT(*)看是否符合预期，最后INSERT INTO real_table SELECT ... FROM temp_raw WHERE valid=1 - 存储过程中需要跨多条语句共享中间状态（比如递归层级、累计标记），又不想污染主表或加额外字段
容易踩的坑：生命周期、可见性、性能反模式
临时表最常出问题的地方不在语法，而在对“会话”边界的误判：
- 连接池环境下，
CREATE TEMPORARY TABLE后如果连接被归还到池中，下次取出的可能是另一个会话复用的连接——临时表已不存在，Table 'xxx' doesn't exist就来了 - 应用里用了长连接但没做连接健康检查，某次网络闪断后重连，旧临时表丢失，新逻辑继续跑却找不到表
- 误以为临时表能提升所有聚合性能：小数据量时内存临时表快，但大数据量下频繁刷磁盘反而比直接走索引慢；先看
EXPLAIN是否真生成了临时表，再决定是否手动干预 - 在事务中创建临时表，然后执行
ROLLBACK——临时表不受事务控制，仍存在；但若事务失败导致连接异常关闭，表就没了
真正关键的不是“能不能建”，而是“要不要让它活过一条 SQL”。一旦涉及连接复用、异步任务、多线程操作，临时表的会话绑定特性就会立刻暴露脆弱性——这时候往往该考虑用普通表加前缀 + 定时清理，或者改用 CTE（WITH 子句）替代。
