临时表默认无索引，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，旧数据残留导致索引统计失真
