临时表JOIN性能差的四大原因及对策：未建索引导致全表扫描；字段类型不匹配使索引失效；数据量过大引发哈希连接退化；命名冲突或作用域不清干扰执行计划。

临时表没加索引，JOIN 就变全表扫描

临时表默认不带任何索引，JOIN 时若关联字段（如 temp_orders.user_id）没显式建索引，优化器只能走 ALL 类型扫描——哪怕临时表只有几千行，每次嵌套循环都触发全表比对，性能断崖下跌。

• 创建临时表后立刻建索引：CREATE INDEX idx_temp_user_id ON temp_orders(user_id);
• 复合索引更优：如果后续还要按状态过滤，直接建 INDEX (user_id, status)
• 避免用 SELECT * INTO #temp 这类隐式建表方式，改用显式 CREATE TABLE #temp + INSERT，方便控制索引

临时表数据类型和主表不一致，索引直接失效

常见错误是把 users.id（INT）和临时表里的 user_id（VARCHAR）直接 JOIN，MySQL 会隐式转成字符串比对，导致索引完全不用。

• 建临时表时严格对齐原表字段类型：user_id INT NOT NULL，别用 TEXT 或 VARCHAR(255) 存数字
• 插入前用 CAST 或 CONVERT 强制转换：CAST(src.user_id AS SIGNED)
• 用 EXPLAIN 看 key 列是否为空，空就说明类型不匹配或索引没生效

临时表太大，哈希连接内存溢出退化成嵌套循环

当临时表超 10MB 或行数过百万，MySQL 可能因内存不足放弃哈希连接，回退到效率更低的嵌套循环，rows 值暴增。

• 提前过滤再进临时表：不要先塞全量数据再 WHERE，而是在 INSERT INTO #temp SELECT ... WHERE ... 里完成筛选
• 分批处理：用 LIMIT + 自增 ID 分段写入多个临时表，再逐个 JOIN
• 调大 tmp_table_size 和 max_heap_table_size（仅限内存足够时），但别超过物理内存 50%

临时表名冲突或未显式指定作用域，引发执行计划错乱

在存储过程或并发场景下，多个会话同时用 #temp 名称，可能被优化器误判为同一张表，导致统计信息不准、驱动表选错。

• 用会话唯一命名：#temp_orders_@@SPID（SQL Server）或 CONCAT('temp_', CONNECTION_ID())（MySQL）
• 显式声明生命周期：CREATE TEMPORARY TABLE（MySQL）或 DECLARE @temp TABLE（SQL Server），避免全局临时表（##temp）的锁竞争
• 用完立刻 DROP TABLE #temp，别依赖会话结束自动清理——长连接下残留临时表会污染后续 EXPLAIN 结果

临时表的“临时”二字容易让人忽略其真实开销，它不是语法糖，而是实实在在参与执行计划的物理结构。索引、类型、大小、命名，每个环节漏掉一个，都可能让 JOIN 速度从毫秒级跳到秒级。