临时表能绕过优化器错误驱动表选择，通过预筛选小结果集（如200行）驱动大表，实现可控执行路径；其自带内存哈希索引与数据压缩优势，提升JOIN效率；分步处理LEFT JOIN链可抑制结果集膨胀；将复杂多表JOIN拆为线性步骤，使EXPLAIN更清晰可调。
临时表能绕过优化器的错误驱动表选择
MySQL优化器在多表JOIN时会基于统计信息估算各表大小和过滤性，自动决定驱动表顺序。但统计信息过期、小表数据倾斜或WHERE条件写法不当，都可能导致它选错驱动表——比如用100万行的orders去驱动5000行的users，触发嵌套循环的O(M×N)开销。而显式建临时表相当于“人工指定驱动表”：CREATE TEMP TABLE tmp_users AS SELECT * FROM users WHERE status = 'active'，先筛出200行有效用户，再拿这200行去JOIN大表，执行路径就可控了。
临时表自带隐式索引与数据压缩优势
临时表不是简单复制数据，它天然具备两个加速点：一是MySQL 8.0+对临时表自动创建内存哈希索引（尤其对JOIN字段），二是你建表时通常带强过滤条件（如WHERE created_at >= '2024-01-01'），实际写入的数据量可能只有原表的5%～10%。体积小 + 索引紧凑 = JOIN时哈希连接更快、落盘临时结果更少。直接多表关联则无法享受这种“预裁剪”红利。
避免LEFT JOIN链导致的结果集膨胀
当查询涉及多个LEFT JOIN（比如订单→用户→地址→优惠券），每层LEFT都会让中间结果集按右表匹配数倍增。一个用户有3个地址、2张优惠券，单条订单就可能膨胀成6行。而用临时表分步处理：SELECT order_id, user_id FROM orders WHERE status = 'paid' → SELECT u.*, a.city FROM tmp_orders o LEFT JOIN users u ON o.user_id = u.id LEFT JOIN addresses a ON u.id = a.user_id，就能把膨胀控制在关键路径上，不波及其他关联。
EXPLAIN里看不到的隐性成本：临时表让执行计划更“线性”
直接写12表JOIN时，优化器要穷举所有连接顺序（n!种），容易超时退化为次优计划；而临时表把复杂查询拆成2～3个独立步骤，每个步骤的EXPLAIN都清晰可见——type是否为ref、rows是否合理、有没有Using temporary。真正难调的从来不是语法，是优化器在黑盒里替你做的决策；临时表就是把它从黑盒变成白盒。
实际生产中，临时表快不快，取决于你是否在建表时就做了精准过滤。没过滤的临时表，只是把性能问题从JOIN阶段挪到了INSERT阶段。
