临时表仅在中间结果小、需多次复用、原表缺索引或关联复杂时有效；盲目使用会拖慢性能、污染连接池；必须显式建索引、窄字段、过滤前置，并用IF NOT EXISTS+TRUNCATE保障安全。
临时表不是自动加速器，建错或不建索引反而比原生 JOIN 更慢。 它只在特定场景下有效：中间结果集小、需多次复用、原表缺乏合适索引或关联逻辑复杂到优化器失智时。盲目套用会浪费内存、拖慢执行、还可能因未清理导致连接池污染。
什么时候该用临时表替代 JOIN
不是所有多表关联都适合塞进临时表。真正值得动它的信号是：
- 某张被 JOIN 的大表（比如
customers）实际只用其中几千行，但 WHERE 条件又无法走索引（如region = 'CN' AND status IN ('active', 'trial')且没联合索引） - 需要三张以上表关联，且中间结果要被后续多个 UPDATE / SELECT 复用（比如先筛出“近7天高价值用户”，再据此更新订单状态 + 插入日志）
- 原 SQL 出现
Using temporary+Using filesort，且EXPLAIN显示驱动表选择错误、type是ALL或index - 业务逻辑含聚合、去重、窗口函数等，MySQL 原生
UPDATE JOIN不支持，只能先算再写
CREATE TEMPORARY TABLE 必须带索引和窄字段
默认建出来的临时表没有索引，等于白建。尤其当后续要用它 JOIN 主表时，没索引就会触发嵌套循环全表扫描——比原 SQL 还慢。
正确做法是显式声明主键或加索引，字段类型尽量窄：
CREATE TEMPORARY TABLE tmp_high_value_users ( user_id BIGINT PRIMARY KEY, -- 必须有主键或唯一索引 last_order_time DATETIME, total_amount DECIMAL(10,2) ) ENGINE=InnoDB; <p>-- 立刻建索引（如果不用主键做 JOIN，就得额外建） CREATE INDEX idx_tmp_uid ON tmp_high_value_users (user_id);</p><p>-- 字段别乱用 BIGINT/TEXT：user_id 能用 INT 就别用 BIGINT，避免内存膨胀
别信 “MySQL 会自动优化” —— 临时表的索引必须手建，且建完立刻用 EXPLAIN 验证是否命中。
INSERT … SELECT 后别直接 JOIN，先确认执行计划
很多人以为把数据 INSERT 进临时表就万事大吉，结果一 JOIN 还是慢。问题常出在：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
INSERT INTO tmp SELECT ...没走索引，导致临时表数据乱序，JOIN 时无法利用主键顺序加速 - JOIN 时写成
ON t1.id = tmp.user_id，但tmp.user_id没索引，或类型不一致（比如t1.id是BIGINT，tmp.user_id是INT），触发隐式转换 - WHERE 条件写在外层，没下推到临时表构建阶段，导致临时表存了 10 万行，实际只用 100 行
安全写法是把过滤条件尽量压到 INSERT SELECT 里，并用 EXPLAIN FORMAT=TREE 看最终 JOIN 是否走 eq_ref：
-- 好：过滤前置，临时表只存目标数据 INSERT INTO tmp_high_value_users SELECT u.id, MAX(o.created_at), SUM(o.amount) FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' AND o.created_at > DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY u.id HAVING SUM(o.amount) > 5000; <p>-- 后续 JOIN 才能稳走主键匹配 UPDATE orders o JOIN tmp_high_value_users t ON o.user_id = t.user_id SET o.priority = 'high';
临时表生命周期和连接池隐患
临时表只对当前会话可见，但连接池会让“同一个连接”被反复复用。如果存储过程里只写 CREATE TEMPORARY TABLE，不加 IF NOT EXISTS 或没做清理，第二次调用就会报 Table 'tmp_xxx' already exists。
更隐蔽的问题是：没 DROP 也没 TRUNCATE，上一次残留数据会影响本次逻辑，且长期占用内存或磁盘临时表空间。
推荐模式：
- 始终用
CREATE TEMPORARY TABLE IF NOT EXISTS+TRUNCATE TABLE开头 - 别依赖会话关闭自动销毁 —— 连接池下会话不关，临时表就一直挂着
- 如果存储过程可能并发调用，确保临时表名带会话唯一标识（如
CONCAT('tmp_', CONNECTION_ID())），避免冲突
最易被忽略的一点：临时表建在 MEMORY 引擎虽快，但一旦数据超 max_heap_table_size，会悄无声息转成磁盘表，性能断崖下跌。宁可默认用 InnoDB，稳。
