临时表比单纯拆SQL更有效，因其能共享上下文、复用已过滤结果，避免重复拉取主表数据；而应用层合并各子查询则缺乏共享列（如t1.id）且无法复用中间结果。
直接拆分多表 JOIN 并不是万能解法，但对超过 5 张表的查询，用临时表缓存中间结果集，确实是最可控、见效最快的手段——前提是临时表建得准、数据过滤得早、索引跟得上。
为什么临时表比单纯拆 SQL 更有效
拆成多个独立 SELECT 再在应用层合并，看似简单，但容易忽略两个现实问题：一是各子查询之间缺乏共享上下文（比如共用的 t1.id 列），导致重复拉取主表数据；二是无法复用已过滤的结果，比如 test3 只要 id 的行，拆开后可能每个子查询都重扫一遍全表。
而临时表把“过滤+索引”这步提前固化下来，后续所有 JOIN 都基于这个小结果集跑，执行计划更稳定，也更容易被优化器识别为“小驱动表”。
- 临时表只在当前会话可见，
DROP TEMPORARY TABLE不是必须操作，但显式清理更安全 -
CREATE TEMPORARY TABLE ... SELECT一步到位比先CREATE再INSERT更少出错 - 临时表默认不走 InnoDB 的 redo log，写入快，但崩溃不持久——这反而是优势，不用担心里程碑数据污染
临时表字段和索引怎么建才不白建
临时表不是原表的镜像，字段越精简越好。只保留后续 JOIN 和 WHERE 里真正用到的列，尤其避免带大文本字段（如 c VARCHAR(200)）——它会让临时表体积暴增，拖慢扫描速度。
索引必须按实际 JOIN 顺序建，且优先覆盖 ON 条件中的等值字段：
- 如果后续是
JOIN temp_t3 ON t1.b = temp_t3.b，那INDEX(b)是底线，没它等于裸奔 - 如果还有
WHERE temp_t3.status = 'active'，就该建INDEX(b, status)，而不是INDEX(status, b) - 主键别随便设
id，除非你确认它会被用于下一轮 JOIN；否则用PRIMARY KEY (b)更贴合访问模式
哪些表适合放进临时表，哪些坚决不能
适合的典型特征：数据量大（百万级以上）、但业务逻辑只用其中一小部分（如时间范围、状态子集、ID 白名单），且这部分数据相对稳定（不频繁更新）。
不适合的几类表要警惕：
- 主表（如
test1）一般不放——它是驱动源，临时化反而丢失过滤时机 - 被 LEFT JOIN 的右表，如果本身行数少（
- 含高频率写入的表（如实时日志表），临时表内容可能刚建好就过期，还增加会话负担
- 字段类型不一致的表（比如
t1.a是VARCHAR(20)，t2.a是VARCHAR(50)），临时表复制时若不显式 CAST，可能引入隐式转换，让索引失效
执行顺序和 EXPLAIN 验证不能跳过
建完临时表后，一定要用 EXPLAIN FORMAT=TREE（MySQL 8.0+）或至少 EXPLAIN 看执行计划，重点核对三点：
- 临时表是否出现在驱动位置（
id最小、type是ref或const） - 对临时表的访问是否走了你建的索引（
key列显示索引名） - 有没有意外出现
Using temporary或Using filesort——这说明 GROUP BY 或 ORDER BY 还在内存外折腾，得调整临时表字段或补索引
最常被忽略的是：临时表建了，但后续 JOIN 没强制用它当驱动表，优化器还是选了别的表。这时候就得配合 STRAIGHT_JOIN 显式控制顺序，而不是赌优化器估算准确。
