临时表能显著加速超大规模数据join，但前提是建索引、对齐字段类型、控制数据量；漏掉任一环节（如未建索引、类型不一致、表过大），会导致全表扫描或嵌套循环退化，性能反而更差。
临时表能显著加速超大规模数据 JOIN，但前提是它被当作物理结构来对待——建索引、对齐类型、控制大小，漏掉任一环节，性能可能比直接写 JOIN 还差。
临时表没加索引，JOIN 就是全表扫描
临时表默认不带任何索引，哪怕只有 1 万行，JOIN 时若关联字段（如 temp_orders.user_id）没显式建索引，优化器只能走 type=ALL 扫描。这不是“慢一点”，而是每次嵌套循环都扫一遍临时表，rows 值在 EXPLAIN 里会暴增。
- 建完立刻加索引：
CREATE INDEX idx_temp_user_id ON temp_orders(user_id) - 复合索引更实用：如果后续还要按状态过滤，直接建
INDEX (user_id, status) - 别用
CREATE TEMPORARY TABLE AS SELECT——它不支持PRIMARY KEY语法糖，也容易把数字字段隐式转成VARBINARY，导致后续 JOIN 失效
字段类型不一致，索引直接失效
常见错误是让 users.id（INT）和临时表里的 user_id（VARCHAR）直接 JOIN。MySQL 会隐式转成字符串比对，索引完全不用，EXPLAIN 的 key 列为空就是信号。
- 建表时严格对齐原表类型：
user_id BIGINT NOT NULL，别用VARCHAR(255)存 ID - 插入前强制转换：
CAST(src.user_id AS SIGNED)或CONVERT(src.user_id, SIGNED) - 用
EXPLAIN确认key列非空，且type是ref或eq_ref
临时表太大，哈希连接退化成嵌套循环
当临时表超过 10MB 或行数破百万，MySQL 可能因内存不足放弃哈希连接，回退到嵌套循环，rows 预估跳变、执行时间从秒级升到分钟级。
- 插入前就过滤：
INSERT INTO temp_batch SELECT id FROM large_table WHERE created_at >= '2024-01-01'，别先塞全量再WHERE - 分批处理：用主键范围切片，比如每次
id BETWEEN 100000 AND 150000，填入新临时表再 JOIN - 调大
tmp_table_size和max_heap_table_size要谨慎，别超物理内存 50%，否则反而触发磁盘临时表转换开销
MySQL 和 SQL Server 的临时表写法不能混用
同一套逻辑抄错数据库语法，轻则报错，重则语义错乱。比如 MySQL 的 CREATE TEMPORARY TABLE 在 SQL Server 里根本不存在，而 SQL Server 的 #tmp 在 MySQL 里会被当成普通表名。
- MySQL：
CREATE TEMPORARY TABLE tmp (id BIGINT PRIMARY KEY) ENGINE=InnoDB，更新用UPDATE t1 INNER JOIN tmp ON t1.id = tmp.id SET ... - SQL Server：本地临时表名必须带单个
#，更新必须用FROM语法：UPDATE t1 SET t1.status = t2.new_status FROM users t1 JOIN #tmp t2 ON t1.id = t2.id - PostgreSQL：
SELECT * INTO TEMP TABLE tmp FROM ...，INTO必须放在SELECT末尾，顺序错直接报syntax error at or near "INTO"
临时表的“临时”二字最误导人——它不是语法糖，而是参与执行计划的真实物理结构。索引有没有、类型对不对、命名清不清、大小控没控，每个点都会直接影响 type 是 ref 还是 ALL，而这个区别，在千万级数据上就是秒级和分钟级的差距。
