临时表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 速度从毫秒级跳到秒级。
