join顺序影响性能，是因为优化器在有限搜索空间中可能未尝试最优路径，尤其表数多、统计不准或left join语义受限时；explain中rows（驱动表行数应小）、type（被驱动表应为ref/range而非all）和extra（出现using join buffer等表明顺序错误）三列揭示实际驱动表。
JOIN顺序影响性能，不是因为SQL写法本身有快慢，而是优化器在有限搜索空间里可能根本没试到最优路径——尤其当表多、统计不准或语义受限时，它连那个快的顺序都不会生成。
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里提前聚合出来的中间表。优化器看不到你脑子里的业务逻辑，只能靠统计信息和语法结构猜。
