JOIN顺序影响性能是因为优化器在有限搜索空间中可能遗漏最优路径；EXPLAIN中rows、type、Extra三列揭示实际驱动表；LEFT JOIN不可随意交换左右顺序，因其语义强制左表全保留。

JOIN顺序会影响性能，是因为优化器在有限搜索空间里，可能根本没看到最优顺序——尤其当表多、统计不准或语义受限时，它连试都不会试那个快的路径。

EXPLAIN里哪几列暴露了实际驱动表

别看SQL怎么写的，直接看执行计划里谁真被扫了：

• rows列：驱动表对应行数应明显更小（注意是过滤后的预估行数，不是原始表总行数）
• type列：被驱动表的理想值是ref、eq_ref或range；若出现ALL，说明它被全表扫描了
• Extra列：出现Using join buffer或Using temporary，基本意味着中间结果失控，顺序很可能错了

LEFT JOIN为什么不能随便换左右顺序

LEFT JOIN的语义强制左表必须全保留，优化器不敢重排——哪怕右表只有10行、左表有1000万行，它也不能把右表拉到外层循环位置。

• 如果左表没加有效WHERE条件（比如WHERE a.created_at > '2026-01-01'），它就大概率变成事实上的驱动表
• 把右表的过滤条件写在WHERE里（如WHERE b.status = 'active'）会悄悄退化为INNER JOIN，还可能误导优化器误判选择率
• 正确做法是把右表过滤移到ON子句：LEFT JOIN b ON a.id = b.a_id AND b.status = 'active'

什么时候该用STRAIGHT_JOIN或/*+ Leading() */

这些强制手段只在明确知道优化器选错时才用，不是常规解法：

• MySQL用STRAIGHT_JOIN：当EXPLAIN显示驱动表rows远大于被驱动表，且你确认左表过滤后确实更小
• PostgreSQL用/*+ Leading(t1 t2 t3) */提示（需启用pg_hint_plan）：多表JOIN时优化器因组合爆炸放弃穷举，而你通过业务逻辑能确定最优路径
• 所有强制手段都必须配合ANALYZE TABLE或VACUUM ANALYZE更新统计信息后再验证，否则可能越调越差

真正难的不是“怎么写顺序”，而是判断“哪个才是事实上的小表”——它可能是大表加了强过滤后的结果集，也可能是CTE里提前聚合出来的中间表。优化器看不到你脑子里的业务逻辑，只能靠统计信息和语法结构猜。