临时表适用于分步处理复杂查询、避免重复计算等场景，通过CREATE TEMPORARY TABLE创建，仅当前会话可见，会话结束自动销毁；需注意内存与磁盘存储转换、合理添加索引、避免频繁创建，并可通过CTE或派生表替代以优化性能。
MySQL临时表是一种在会话期间存在的特殊表，它只对当前连接可见，常用于复杂查询中存储中间结果。合理使用临时表能简化逻辑、提升开发效率，但在性能方面需谨慎处理。
临时表的应用场景
临时表适合以下几种典型情况：
- 分步处理复杂查询：将一个多层嵌套的查询拆解，先将中间结果存入临时表，再进行后续关联或过滤，提高可读性和执行效率。
- 避免重复计算：当某个子查询被多次引用时，可将其结果保存到临时表，减少重复扫描源表的开销。
- 大批量数据预处理：在导入或迁移数据过程中，用临时表暂存清洗后的数据，再统一写入目标表。
- 存储过程中的中间数据：在存储过程或函数中，需要缓存阶段性结果时，临时表是一个安全且隔离的选择。
临时表的创建与使用方式
使用 CREATE TEMPORARY TABLE 语句创建临时表，语法和普通表一致：
CREATE TEMPORARY TABLE temp_sales AS SELECT * FROM sales WHERE sale_date > '2024-01-01';
该表仅在当前会话可见，会话结束自动销毁。你可以在同一个会话中对它进行查询、更新或与其他表连接。
注意：临时表可以与普通表同名，此时普通表会被隐藏，只能操作临时表，直到其被显式删除或会话结束。
性能考虑与优化建议
虽然临时表方便，但不当使用可能带来性能问题：
-
内存 vs 磁盘存储：小临时表通常在内存中（使用Memory引擎），速度快；但若包含TEXT/BLOB字段或超出
tmp_table_size/max_heap_table_size限制，则会转为磁盘表（MyISAM或InnoDB），显著降低性能。 -
索引设计：临时表默认不带索引。如果后续要频繁按某字段查询或连接，应手动添加索引，例如：
CREATE INDEX idx_user ON temp_sales(user_id); - 避免频繁创建/销毁：在循环或高频调用的存储过程中反复创建临时表，会增加元数据开销。可考虑复用或改用表变量（如支持）。
-
监控临时表使用情况：通过
SHOW STATUS LIKE 'Created_tmp%tables';查看内存和磁盘临时表的创建次数。若磁盘临时表过多，说明需要优化查询或调整配置。
替代方案参考
并非所有场景都适合用临时表：
- CTE（公用表表达式）：对于简单的一次性中间结果，使用WITH语句更简洁，且优化器可能直接内联处理，避免物理生成。
- 派生表（子查询）：短生命周期的数据可用子查询代替，减少对象管理负担。
- 内存表或缓存层：跨会话共享中间结果时，可考虑使用Redis等外部缓存，而非依赖数据库临时结构。
基本上就这些。临时表是有力工具，关键在于判断何时该用、如何控制资源消耗。结合实际执行计划和状态监控，才能发挥其优势同时规避性能瓶颈。
