临时表默认无索引，JOIN时触发全表扫描导致性能更差；必须在INSERT后立即对JOIN字段建索引（如PRIMARY KEY或INDEX），确保与ON条件完全一致，否则仍走type=ALL。

临时表默认没索引，JOIN时直接全表扫描

很多人建完 CREATE TEMPORARY TABLE 就急着 JOIN，结果发现比原表还慢。原因很简单：临时表不带任何索引，后续对它做 JOIN 或 GROUP BY 时，优化器只能走全表扫描——哪怕只有 5 万行，type=ALL 也会让执行时间翻倍。这不是数据量问题，是结构缺失。

为什么加索引后 JOIN 跳转变快？

临时表加索引的核心价值不是“查得快”，而是让 JOIN 算法降级为更轻量的路径：

• 有索引后，INNER JOIN 可能从哈希连接（Hash Join）退化为嵌套循环（Nested Loops），但因内层能走 ref 或 eq_ref，实际更快
• 索引字段若为整型且高选择性（如 order_id），MySQL 8.0+ 会自动在内存中构建哈希查找结构，匹配效率接近 O(1)
• 没有索引时，EXPLAIN 中常出现 Using join buffer；加索引后消失，说明连接已脱离缓冲区暴力匹配

建什么索引？哪些坑必须避开？

不是所有索引都管用，关键看 JOIN 条件和写入方式：

• 必须在 INSERT 后立即建索引，不能等 UPDATE 前再加——否则中间步骤已触发全扫
• 索引字段要和 ON 条件完全一致：如果写 ON o.id = t.order_id，就得在临时表上对 order_id 建 PRIMARY KEY 或 UNIQUE INDEX
• 避免用 CREATE TABLE ... SELECT 创建临时表：它不支持 PRIMARY KEY 语法糖，容易漏掉关键约束
• 字符型字段要留意排序规则，比如 utf8mb4_unicode_ci 和 utf8mb4_general_ci 混用会导致隐式转换，索引失效

临时表索引不是万能加速器

加了索引仍慢？大概率是下面某个环节没对齐：

• 目标表（被 JOIN 的那张主表）关联字段没索引，比如 orders.user_id 没 B+ 树索引，临时表再快也没用
• 临时表数据来自模糊条件（如 WHERE name LIKE '%abc%'），无法建立高效等值匹配索引
• 单次只更新几百行却硬上临时表——创建、插入、建索引、JOIN、销毁的开销，可能超过直接 WHERE IN
• 事务里反复重用同一张临时表但没 TRUNCATE，旧数据残留导致索引统计失真

真正卡住性能的，往往不是“要不要建索引”，而是“在哪建、建给谁用、建完有没有被真正命中”。临时表索引不是开关，是精密校准。